Stardot Multi-Channel Long Distance Coaxial (MCLDC)?
Anyone have any experience or advice on using Stardot's Multi-Channel Long Distance Coaxial offering?
Some screenshots of their approach / options:
It has potential for far-flung installations where cameras are more than ~300 feet (100M) apart.
It is not the only option for this sort of application (For example, we discussed a similar PoE product here, as well as SLOC).
This Stardot offering shares many of the same weaknesses:
- proprietary
- locks you into Stardot (not a major supplier)
- must pick from 5 MCLDC model cameras only
I dug around on pricing and found that MCLDC cameras have a project street price range between ~$400 - $500 each, and the 4 channel receiver is about ~$200. Pricing of 'pure IP' equivalents that beats these prices is common, and growing.
Whether or not this proves to be less expensive that 'traditional' cabled projects ultimately depends on install difficulty and amount of total cable needed. In general, smaller jobs (<16 cameras, mostly indoor locations) simply would not gain much advantage over traditional ethernet camera designs.
I don't know this vendor in particular but we are already using such IP configuration over coax TV antenna for IPTV for example or internet But you need IP , that 's why Stardot is using IP Hybrid Security Camera, like Sony Sloc's. But Sony doesn't promote multiple shared connections.
PowerLine communication over coax IEEE 1901 (200 and 500 mb/s) can work on bandwidth sharing using 2-30 or 2-68 Mhz frequencies on the coax up to 600 meters. Real Throughputs are +/- 65 Mbits with 200 mb and 180 Mb/s with 500 Mb.(180 Mbs measured is great)
Advantage is to use Tree topologies like analog TV did ...and you can extand length, does support also POE. One master and several slaves.
Sloc is using according to what I know a customized PLC (keeping some coax frequencies for analog and some for IP) so you don't have the full theorical bandwidth and resolution / streams are for such reasons, limited, and also analog is reduced ( you don't have a full 4CIF...)
Moxa (multimedia over coax) technology is also using shared bandwith but over 1 Ghz (so good at home, but not convenient for long distances)
Hello,
I work for StarDot Technologies and just wanted to share some information about Multi-Channel Long Distance Coaxial that I hope will clarify things for you. MCLDC is a new technology that we have been developing for some time, and we are very excited about the potential for MCLDC in the security market.
Here are the facts:
- MCLDC cameras utilize DVB-T video transmission to transmit megapixel video through coaxial cable. DVB-T is the digital television standard for most countries around the world, and truly is a common sense method to transmit high resolution video. This technology is by no means proprietary; we are just the first to develop this technology for security surveillance.
- Because MCLDC cameras transmit DVB-T, it is possible to connect up to 16 cameras on a single coaxial cable. The best way to visualize this is to think about how cable and satellite television works in your home, and all of the channels that your set top box receives through the coaxial cable. MCLDC is the exact same concept, except your set top box is the MCLDC channel receiver. DVB-T is a very reliable method of transmitting video signals, and is a proven solution in television broadcasting.
- Another reason why DVB-T is a common sense solution for surveillance cameras is the distances that can be achieved through coaxial cable. If using RG59 coaxial cable, cable run distances of up to 1200ft can be achieved. Even greater distances up to 3000ft can be accomplished by using high quality RG6 coaxial cable; this would significantly reduce installations costs when compared to fiber optic options currently available in the market.
- The MCLDC network channel receiver supports 4 cameras; this is an ONVIF Profile S compliant device so an installer will not be locked into using a specific recorder. We have already had some MCLDC projects use ExacqVision as the VMS.
Here are the benefits to an installer/end-user.
- MCLDC is a true retro-fit solution, meaning the end user can save a significant amount of money on a CCTV upgrade by keeping the coaxial cable that is already in place. The cost of the MCLDC cameras and channel receiver are competitive when compared to HD-SDI and IP over Coax solutions, and the overall cost will compete against any IP installation.
- An installer can easily add more cameras to an MCLDC security system, the daisy chain topology means that adding a new camera is as simple as connecting a coaxial cable from the nearest camera.
- MCLDC cameras also simultaneously transit analog video, which is primarily use for focus use but can be transmitted down the same cable as the megapixel transmission. This can be used to utilize analog monitors that are already in place, for example in a retail store or a casino that wants to watch the surveillance cameras on their existing monitors.
- Being able to add 16 cameras to a single cable will alleviate issues such as limited conduit space, having to install multiple cable runs (adding to the overall cost of an install). Existing CCTV installations can also be expanded at a minimal cost.
We are primarily marketing MCLDC as a retro-fit solution, we understand there is a demand for megapixel but often the costs associated with an upgrade will affect the final decision. Installers bidding on IP installations will usually have to offer their labor at the lowest possible cost in order to compete. Any installer that can offer their customers MCLDC as a solution to upgrade their surveillance system will be more competitive, and will be able to (we hope) make more money for their time. We expect more customers will be enticed into upgrading their surveillance system because they can re-use the cabling infrastructure they have already invested in while saving money on a better system.
Just a little note about StarDot Technologies, we are a California based company and have been engineering imaging technology since 1994. We released our first internet camera in 1998, and have since developed IP cameras for both the tourism and the security markets.
From a partner VMS perspective, we saw enough promise in this hardware technology that we have made sure to do a much deeper integration for our upcoming V2.2 release next week. I've been quite impressed with how well the two technologies are recieved during demonstrations. At ISC, they will be showing it running on our software on one of their screens.
Thank you Nathan & Ben, I will be sure to stop by the booth. The reason we had not quoted StarDot's MCLDC was it limited just to 5 Star Dot cameras and their own VMS. We have many old plants in our area that we have run alarm and fire alarm system wires very similar to Star Dot's architecture. In these plants keeping the camera runs under 328 feet are difficult even with a makeshift IDF. Not everyone can afford a fiber run either. I still have my doubts but this solution maybe an option for us in future.
05/22/14 05:00pm
Ben Kirk of Stardot was kind enough to come in and show us these cameras today, and I was highly impressed.
First, it's a forklift upgrade. Quoted distance is 3000' on RG6 and 1200' on RG-59/U.
Second, you can daisy chain cameras, which- woah, mind blown. Put a T connector on an existing camera, run a coax cable to a second camera, and boom, done. Assuming you have a free channel on the decoder. Ben even said you can run redundant coax cables so snipping a wire won't take out the camera. The literature claims up to 16 cameras on a single coax cable (they're only launching with 4 channel encoders, though). This is, in my opinion, the clearest advantage over HDCVI.
Third, DVB-T is capable, in theory, of extremely high resolution video. I'm just speculating here, but I'll bet we see practical 4K cameras in a couple of cycles.
Obviously, this isn't going to be for every installation, but as I've been saying since I first heard about HDCCTV, idiot proof HD surveillance that is easier to install than IP cameras, reuses existing analog infrastructure, and and doesn't require networking knowledge to program or operate can only be a good thing for the surveillance industry in general.
More info on StarDot's website here. There is a case study, which I thought was pretty cool, and it'll be launching in about a month.
But you need to use StarDot's cameras, right?
Remember these guys? PoE Chain IP Cameras
It's a hard application if you are constrained to a small manufacturer with a limited line. Yes/no?
| 05/22/14 05:30pm
It's a hard application if you are constrained to a small manufacturer with a limited line. Yes/no?
Of course it is, but the cost of experimentation/adoption is lower in this case because 1) you can resuse existing coax and 2) you can use ONVIF S NVRs, so if StarDot goes kablooey, you can use anyone's cameras. If it was proprietary end-to-end, I wouldn't have wasted the time to type all this up, I've been burned on proprietary stuff that the manufacturer swore was the wave of the future far too many times. Which is why I don't sell much HDCCTV, frankly.
In fact, you can mix StarDot cameras and normal IP cameras in the same location. I don't even think they make an NVR. So cost of entry is the NVR you would have bought anyway to record your IP cameras. It's significantly cheaper than ip-over-coax, and cheaper than most megapixel cameras (if you consider the cost of not just the camera but of running CAT5 when you've got perfectly good coax in place already).
I don't think I'd recommend this for a greenfield installation, but it's an interesting possibility if 1) you want to yank existing analog cameras and DVRs and replace them with HD video or 2) if you want to have an extremely long run (3000' of RG-6 is cheaper and easier to run that dropping a switch every 300 feet, or running fiber, or whatever).
My metapoint is that, for this architecture / deployment approach, you can only use Stardot cameras, correct?
And Stardot's options are fairly limited, both in form factors and feature sets, so there's a big tradeoff for a lot of people, even if the overall cost is lower because of the install/cabling savings. Yes/no?
| 05/22/14 06:30pm
I guess? Although that probably won't be a factor for most, as their product offering at launch seems more comprehensive than you'd expect.
My metapoint is that, for this architecture / deployment approach, you can only use Stardot cameras, correct?
There are currently 4 other large manufacturers developing surveillance cameras that will utlize DVB-T transmission.
DVB-T is not proprietary, it is the digital television standard for Europe, Asia and Australia. Meaning there are DVB-T products already on the market that can support DVB-T cameras….HD televisions for example.
It is a common sense solution for transmitting high resolution video, just think how reliable your cable or satellite TV is… it is the same concept except we are using it for surveillance.
This is, in my opinion, the clearest advantage over HDCVI.
The trade-off is we're back to camera side compression?
All this network re-inventing stuff is a bit ironic, no? Most combinations of technological tuples are still valid: Choose one from column A, one from B, and one from C...
A) Media - Balanced vs. Unbalanced
B) Transmission - Shared vs. Dedicated
C) Architecture - Hub-Spoke vs. Ring
-----Examples-----
10BASE-T - A Balanced Shared Hub
Stardot MCDLC - A Unbalanced Shared Ring ?
P.S. Wasn't Ben with Starfleet originally? :)
| 05/22/14 07:17pm
Wasn't Ben with Starfleet originally?
Budget cuts. Blame the Starfleet Directorate of Personnel.
The trade-off is we're back to camera side compression?
I never understood this complaint. Who cares which side handles compression, as long as it's capable?
Besides, the choice isn't between an IP camera and an MCLDC camera, it's between an MCLDC camera and an analog camera, or between reusing existing coax or rewiring with CAT5. Or using coax over IP, which, seriously, has anyone ever voluntarily used coax over IP?
The trade-off is we're back to camera side compression?
Camera side compression is going to be preferred as resolutions get higher and higher, data throughput is limited regardless of the means of transmission (be it network or DVB-T). It makes sense to have the compression on the camera end so it can be controlled before clogging up the network.
P.S. Wasn't Ben with Starfleet originally? :)
Dammit Man.... I'm a salesman, not a captain!
It makes sense to have the compression on the camera end so it can be controlled before clogging up the network.
It sure does. On the other hand you could just get rid of the network instead, right? Put aside your admittidly awesome daisy chaining solution for a second, since its a hybrid and a special case, and see how it fits in after we establish a baseline.
Let's just talk about the 99% of wired surveillance solutionsout there for a moment as we also drop our pre-conceived notions and biases (Cal?), as much as possible. Maybe even imagine that a video inspector from the planet Vulcan (your namesake once visited, I believe) has arrived to aid us and so he is supremely logical and entirely unemotional as he reviews Earth's technology.
What he might see on his first high level pass is this: A camera with a sensor that transduces light into an electrical signal, that then is transmitted via an electrically conducting wire over a distance, to a device which records that signal. This seems logical, to the Vulcan and so he approves so far.
But then on the second pass, as he encountered IP cameras, the exchange is as follows:
Vulcan: What is this complex modulation of the electrical signal that you are performing before transmission?
Us: Oh, we're just compressing the signal 10 to 1, (with only amazingly small to moderate hits to quality and framerate and latency), so we can save big-time on bandwidth and storage, kinda clever eh?
Vulcan: I see... Are you doing that because that wire doesn't have the capacity to transmit the full-frame rate, uncompressed video?
Us: No, it doesn't, not the way we're doing it at least. You see we have also developed, at no small expense, a complimentary packetized network delivery system that allows multiple nodes to share the medium to acheive a higher utilization than a single node could ever. If we didn't compress it, then the network would get clogged.
Vulcan: Logical and sensible. One question, up to how many camera nodes are you typically muxing on that one wire?
Us: Typically up to one, until of course you get to the big switches, that's where the real magic happens...
Vulcan: WTF? Why don't you skip all that processing at the camera that you are doing, and get the video out to that screen, pronto, and at the same time have the server side motion detection work on a unartifacted frame without expending cpu decoding it first? And if you need to scale, just extend that synchronous wire out to parallel encoders who just write to the SAN without involving the VMS at that point at all...
Us: Hold on, you don't understand the history of how we got here, y...
Vulcan: Earthling, the purpose of the wire is to get the video out to the viewing clients and then the storage, in the fastest, highest quality way. If each camera has its own wire that can do that already, then why are you messing with it?
Me: Tell'em Mr. Kirk!
Spock: Jim, is that really you?
Kirk: The name is Benjamin, actually, nice to meet you...
So what I'm saying is in the case of one camera, one wire and one port why do you need a network? Of course MCLDC allows multiple cameras on one wire and therefore is a valid reason for a network...
Ben, in your MCLDC setup you can do 16 channels correct? Is each channel a pre-allocated slice of the total cable capacity? Or can it be distributed based upon requirements? Also, you make it clear that DVB-T is not your own proprietary standard, and therefore not evil. But technically that's just for the the individual channel?
The 16 channel wrapper thingy is your own secret sauce, yes/no? And therefore no merely DVB-T compatible equipment could simply decode the stream with out it being first de-muxed, yes/no?
Meanwhile, the chief engineer has been listening to this conversation and looks anxious to join in.
Kirk: You got something to add Scotty?
Engineer: Well Cap’n, it's just that...
Kirk: Speak up! I’m sure our Vulcan comrade enjoys a lively discussion as much as the Klingons do.
Engineer: The inspector is correct that the video should be gotten to the screen pronto, but he’s not entirely correct in implying it can’t be compressed in the camera and get out just as fast. And artifacting from compression can be less significant visually than a lack of good color processing on the original image.
As I understand it, in this time period there are 2 mainstream non-IP based coaxial technologies, HD-SDI and Digital Television. HD-SDI methods involve a primitive form of encoding called NRZI, and also convert from the sensor’s bayer filter order into YCrCb color space. So a processor of some kind is needed in this type of camera and there will necessarily be multiple video lines of latency. Then as the inspector mentioned, another processor is needed on the receiving end to encode the data for storage. This culture has yet to invent replicators, so trivial things like soldering micro-wires to silicon chips and then encasing them in plastic will add costs. If it could be done on the camera side in a single package while adding only the same few video lines of latency as the HD-SDI method, but with more color processing operations to enhance the live display, that approach would be superior.
As for encoding latency, the first frame of the compression method used in Digital Television is a key frame, and not dependant on any previous information. This can be transmitted as encoded data in as little as 16 scan lines if a massively parallel process is used. Once you have such a parallel processor, it’s easy to perform billions more color processing operations per image. And so the Digital Television method potentially costs less because it needs just one chip from image to finished storage, need not add perceivable latency, and is capable of producing a superior live display.
The most significant latency would occur in the recording/display device. But if sending relatively uncompressed data has any advantage over highly compressed data, it need not be more than 1 frame. Careless buffering logic will typically add more than that. Also, existing Digital Television monitors can be used with Digital Television cameras, removing any need for the recording device to expend CPU power on the live display. That would free up more CPU power for such things as transcoding to remote cell phone displays.
The Digital Television standard is also more appealing because it employs advanced mathematics to distribute the signal over more than 6000 carrier waves per stream, as compared to the primitive single or double differential signaling used by HD-SDI. With so many carrier waves, it can carry far more data at lower frequencies than HD-SDI, on multiple television channel streams. Lower frequencies travel further in coaxial cabling and have more robust behavior in poor quality cabling. They can even be diverted through the air for short distances.
@Ari
Who cares which side handles compression...
Most people don't. But the people that do, really do. For example: You know the 'city' right? I used to live in Midtown on 7th between Times Square and the Park. Within gun earshot of where they got 'Pac.
You know how they have all those pricey high-rise towers where two elevator doors open into a ground floor 'lobby' thats about the size of a 'bridge and tunnel' person's kitchen? And about 5 feet from the sidewalk's chaotic foot traffic 24/7?
You got your guard and some of sort of desk or podium, and traditionally the b&w b&h squarish monitor that I'm sure you know far more about than me. I used to know the guard in my building pretty well. He said he's got 5 secs to react, to hit the lock button or the panic button or fight or run... He would always have an eye on the quad with street level and 2nd floor (looking down) views.
They didn't have IP cameras back then so I couldn't ask him, but I'm pretty sure he never heard of compression, but just as sure that he wouldn't wanna give up any latency, MP or not. You know there is a bit of unsung value in those old uncompressed analog systems, they can't fool you like the new ones can. They make you believe in their reality! If the monitor is showing the lobby is clear, you can count on it!! Systems today with their jitter and judder and reduced frame rates, never make me think I am doing anything than watching the past...
Sorry for the rant, I'll come up with a less anecdotal response later...:)
You got your guard and some of sort of desk or podium, and traditionally the b&w b&h squarish monitor that I'm sure you know far more about than me. I used to know the guard in my building pretty well. He said he's got 5 secs to react, to hit the lock button or the panic button or fight or run... He would always have an eye on the quad with street level and 2nd floor (looking down) views.
The latency in the high resolution MCLDC output is 450ms, all MCLDC cameras also have simulatenous analog out which provides another video output with no latency. In this case both the high resolution and the analog can be injected into a single coax cable, then on the other end split it off into two, the analog into a the traditional monitor for live viewing and the high resolution stream into the NVR.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Burglars Steal 4G Camera, ~$8,000 In Tools, Camera Is Still Transmitting Video From Burglars Home.
(4)
Started by
Jermaine Wilson
|
4
|
less than a minute by Ryan King |
|
Started by
Lee Jones
|
5
|
less than a minute by Lee Jones |
|
Started by
Undisclosed Manufacturer #1
|
10
|
about 6 hours by Undisclosed End User #5 |
|
Video Surveillance Show Armed Suspect Trying To Enter Club, Security Intervenes, Fight Breaks Out
(9)
Started by
Jermaine Wilson
|
9
|
about 7 hours by Ryan King |
|
Started by
Undisclosed Manufacturer #1
|
9
|
about 11 hours by Undisclosed Manufacturer #4 |
