Separate names with a comma.
Discussion in 'TiVo Series3 HDTV DVRs' started by bdraw, Jul 19, 2007.
It's possible that it isn't SDV in St Petersburg, while similar, the systems are not identical.
That's like saying most people think of a BMW as a car. This is true. The problem is, you have a Mercedes. They are both cars, but a BMW is not a Mercedes.
A CableCARD 2.0 STB is one type of a two-way device that uses a CableCARD to control access (it can also use DCAS to control access). The STB you have is another type of a two-way device that uses CableCARD to control access. But the former is not the same as the latter.
Best place I can send you for education is this Wiki page. Note the following: "Cable Companies have required OCAP as part of the Cablecard 2.0 specification".
The definition of CableCARD 2.0 is not open to debate or opinion; it is rigidly defined by CableLabs.
We all hate to see misinformation on such an otherwise useful forum. It decreases the signal to noise ratio and really confuses people who are trying to educate themselves by coming here. Please consider modifying your thread title.
Not a good analogy, 'cause it's not true. TiVo would be a better one since many people think of a DVR as a TiVo.
Also from this source Cable companies have stated that two way communications by third party devices on their networks will require them to support OCAP. It does not say that the specification requires OCAP on 1st party devices. Let me see if we can get dt_dc to chime in, if anyone has actually read the specification, it would be him.
I'm not debating the definition, just that this box fits the specification.
I still don't see how you made the leap from The Cable Box works with SDV and It's Cablecard 2.0
Am I missing something? Does it say Cablecard 2.0 on the card itself? that wasn't clear from the photos.
As other's have said, just because the box is doing 2 way communication, it doesn't mean that it's using the cablecard to do that.
I really think you should change the title of your article
CableCARD 2.0 is a host device specification, not an actual card, so no the card won't say anything.
The point of contention is, does this 1st party device fit the 2.0 host device specification even though it doesn't support OCAP?
Simply no, given what that Wiki states. Its two-way functionality is proprietary.
No. First off, a cable company is not obligated to support cablecard 2.0, they are not obligated to buy cablecard 2.0 boxes in order to do two way. They are obligated to support cablecard 1.0 devices, supply cards conformant with the 1.0 spec, and since July, all new boxes they supply must use cablecards.
The 2.0 spec explicitly states that OCAP is a requirement for both 2.0 hosts and 2.0 terminals:
When wading through the cablecard specs, it is useful to note that in most cases "Cablecard" has been replaced with "Open Cable", a label that is a classic example of Cable doubletalk to describe their closed system. So "the CableCard 2.0 Spec" is now known (at least in cablelabs land) as the "Open Cable 2.0 spec". They just want to get us in the habit of saying "open" every time we use the word "cable".
ClassicSat- boxes could use the out of band (OOB) rf support which has a standard but my understanding is that the actual pattern of signalling is proprietary as you state. My understanding is that the cable companies don't like this sort of proprietary signalling for a number of reasons- besides inefficiency with high data rate signalling, they don't like the vendor lock in to specifici head end equipment. Most likely the new boxes would use the Docsis protocol also mentioned above, because it is where they are going to avoid these issues.
Ben, dude, you're killing me. Read up on NPH (Non-Portable Host) boxes. That's what you've got there. It *technically* doesn't fulfill the definition of a CableCARD 2.0 device, and really, it wasn't meant to. It was a stop-gap measure for the industry to provide a set-top that adheres to the FCC mandate for separable security but falls short of the portability requirement stipulated in CC 2.0.
Sure enough, I get "channel not available" when trying to tune my S3 to 694. I wonder if I should call and complain and see what BHN says.
It may be a bit misleading, but one of the points I wanted to make was how the Cable companies are attempting to elude the FCC, more specifically to point out that the current mandate is ineffective. Most who think they know what a CableCARD is, believe 2.0 means two-way. I have previously written posts explaining that this is not the case.
CableCARD is all about separate security, that is the entire point of the technology. If you take a cable box and switch out the security then yes, my understanding is that is enough to make it CC 2.0.
Thanks for the clarification about the fact that this box is a Non-Portable Host. Can you explain to me why an NPH doesn't *technically* fulfil the definition of a CableCARD 2.0 device?
Definitly, I'd be interested in hearing back if the CSR actually have a clue about the problem now. They didn't when I called.
Justin already wrote this but it seems you skipped the post. There is no distinction of 1st party vs 3rd party.
The CableCARD 2.0 specs state the function list of a 2.0 set top box
If the box you have satisfies the functional requirements, it can be submitted to be certified as CC2.0. If not (for example it doesn't support OCAP 1.0) then don't bother submitting it, it doesn't meet the basic functionality requirements.
I believe upon further reflection you will find you have a cable set top box that happens to use a M-Stream CableCARD. It supports VOD/PPV/Interactive Guide services, but does not do so using a CC2.0 compliant platform. As such, it should not be referred to as a CC2.0 device. Instead it should be called a set top box that uses CableCARDs and supports 2-way services.
If you'd like to bring attention to the fact that cable MSOs can implement 2-way services using CableCARD without needing to comply with CC2.0 specs, while 3rd parties need to comply with CC2.0 specs and that this situation is unfair, then please do that. Using the wrong terminology will only lead to further confusion.
Thanks for spelling it out for me, I hope you understand that I didn't have time to digest that 133 page document that was very technical.
I hear what you guys are saying, but it contradicts my understanding, which I gained by talking to CableLabs. I have emailed them for some clarification, but just in case I will change both titles.
Maybe the cable companies should create a Unidirectional CableCard Channel lineup.
It might be doable, just not map the channels that are unavailable to linear static authorization cable (non SDV, non PPV, non VOD).
Of course, you can't add SDV channels just for Cablecard users; that would eliminate the purpose of SDV altogether.
At minimum, the two-way functionality is built and coded to the "provider's " format, not the OpenCable 2.0 "standard".
At most, and it seem it is the case, it is essentially a standard Scientific Atlanta cable box with a cablecard for conditional access rather than a built in chip.
"Since OCAP is not a prerequisite and most MSOs will not have a complete
OCAP head-end and system architecture implemented by July 2007, Motorola
provided an alternative reduced-risk solution known as the Non-Portable Host
(NPH) or leased set-top.
The Motorola Non-Portable Host provides MSOs with a separable security
solution having equivalent functionality to current embedded (DCT) set-tops. The
NPH solution provides MSOs with a transition path to separable security set-tops
to address the FCC ban with a migration path to future OCAP deployment.
Manufactured under CableLabs' Non-Portable Host license, these special
set-tops cannot be sold at retail and are not CableLabs Host
2.0-compliant." - Motorola
#3 on OpenCable Host 2.0 specifications..."Require portability. FCC regulations adopted under the "retail availability" provisions of the Communications Act provide for retail cable navigation devices to operate with CableCARDTM modules. The OpenCable system permits "point-of-deployment decisions" for network, security and operator-programmed user interfaces to enable the anticipated variety of retail devices and promotes the portability of such devices."
despite it being their charter, I would not rely solely on cable labs to clarify cable card standards. They do have a heavy bias toward cable companies and would most likely let the idea that cable company boxes are working on CC 2.0 spec go by unmediated. It is in their interest for such thinking to bolster the current standard as working in the minds of policy makers
Key term here is "anticipated variety".
Cable anticipates/hopes that customers will want to buy network computer services from them, which would include traditional video services as well as interactive applications that one might find on a personal computer. In anticipation of the reluctance of CE companies to build such expensive OCAP client boxes for such network computer services, CableLabs tied services that consumers want (changing channels) to services that consumers are indifferent to (placing orders for home shopping network using interactive software on the Set top box).
Maybe folks will want to buy such network computers from cable companies. They are entitled to try to sell such services.
What is completely reprehensible is this idea from the cable companies that they can hold basic channel changing hostage in order to force Consumer electronics companies to help them build and promote such a system.