Jerrold technical info Part 3: Breakdown of the data channel
johnw...@my-dejanews.com
Jerrold technical info Part 3: Breakdown of the data channel
Now that a basic introduction has been given (and hopefully understood), we
can start examining system operation in greater detail. Note that we will
expand on many things mentioned in earlier posts, since the earlier posts
were intended as an easy to comprehend introduction certain details were
simplified or skipped over. Thus here as we go into detail we may appear to
be contradictory to earlier simplified explanations.
What sort of commands are actually carried on the data channel ?
The data channel is used primarily for subscriber management, so as you may
expect there are sets of commands that control functions such as adding /
removing channels, turning on a new box, selectively enabling features (such
as the remote control), turning off a box whose owner hasn't paid etc.
Subscriber management - Connection and Disconnection
06 F8 LA LA LA LA CHK - Disconnect, turn off box used on people who don't pay
their bill ! Box displays the barker channel on all channels.
06 F9 LA LA LA LA CHK - Reset Disconnect (double -ve = turn box BACK on)
Note: This command turns a box back on AFTER it has been disconnected it
won't on its own enable a new box,
Global timer :
When the system was designed Jerrold considered an attack on the system (it
seems like one of the few times :) where the box owner got smart and blocked
the data channel so the cable co. couldn't turn the box off. Their solution
was to put a countdown timer into the box. If the box didn't hear a command
to reset the timer every so often then it would shut down. They implemented
two commands to reset the timer, one GLOBAL and one specific.
These are: 07 FD 8E LA LA LA LA CHK - where the box only resets its
timer if it sees it own address in the command. 03 FD 6E CHK - This is
the global variant this resets the timer on every box that sees the command.
A lot of people have confused the reset timer commands with the reset
disconnect commands (Ourselves at one point and magicboxes included - see
their webpage). They are DIFFERENT this is why a lot of boxes that have been
cubed shutdown after 2-3 weeks, because the designers keep sending F9 reset
disconnect rather than FD 8E reset global timer commands. Jerrold also put in
the flexibility to vary the timeout period depending on the number of boxes
on a particular system and how quickly they could be reset. This timeout
period is set in the initial boot up of a box.
Aside: Have a look at the difference between the global and specific
commands we have mentioned. Can you spot a pattern ? It seems as though
specific commands are often the same as the global commands with 0x20 added.
0x20 corresponds to bit 5 in a byte.
Our theory is that the box differentiates between GLOBAL and SPECIFIC
commands by checking bit 5 of the command byte. If the bit is set then the
command is SPECIFIC, if it is clear then the command is GLOBAL. On small
microcontrollers it is often a pain to do a compare to see if one value
equals another, it is much quicker to check a single bit and use it as a
flag.
There are also the commands to perform routine functions on all boxes in the
network. These are all GLOBAL COMMANDS, they affect every box on the network.
These are thing like setting the channel names for the onscreen display,
setting the clock in the box, changing scrambling mode, turning on / off
channels that end at particular times i.e. enabling the adult channels after
midnight.
From our experience, the biggest consumer of data channel bandwidth are the
commands controlling which channels are enabled on your box. The Head End
Controller seems to sit in a relentless (paranoid ?) loop cycling through all
boxes registered on the system reloading into them the channels that they are
authorised to view.
The actual commands they use are the same commands we illustrated in the
first document, the channel enable now act as disable commands also by
setting the bit in the bitfield to each channel to a 1 or 0 for enable /
disable.
recalling :-
07 E9 LA LA LA LA xx CHK
07 EA LA LA LA LA xx CHK
07 EB LA LA LA LA xx CHK
...
up to 07 F7 LA LA LA LA xx CHK
where xx represents a bitfield for a group of 8 channels.
The E9 command controls channels 0 -7, EA controls channels 8 - 15 and so on.
Command Compression :
Intuitively the specific commands we have covered are very inefficient in
terms of size and consequent bandwidth utilisation. The trade off is that it
is much more secure to address each box individually to prevent
unintentionally activating an authorised box, but it takes an enormous amount
of time to cycle through all commands for all boxes. What would be nice would
be a way to address a range of boxes at the same time, whilst still affording
the flexibility to set the parameters for each box individually. Jerrold
thought this as well, more than just convenient it becomes essential when you
have networks with 100,000 plus boxes on them !
It is easiest now to give an example of command compression and explain it
afterwards.
recall disconnect box command 06 F8 LA LA LA LA CHK
As discussed before LA LA LA LA refers to the 4 bytes of the box's address.
This command could be compressed to
nn F8 LA LA LA 00 01 02 05 06 14 CHK
What has happened is that the first 3 bytes of the ADDRESS are still fixed
but we are specifying MULTIPLE BOXES that have different last byte addresses.
i.e. in this command nn refers to the length it is not a fixed value now
because they can address between 1 box (the command as normal) and 64 boxes
(because the last byte address can only vary between 0 & 3F as discussed in
the first document in the section referring to address formation).
What this command has now done is to shutdown all boxes with addresses :-
LA LA LA 00
LA LA LA 01
LA LA LA 02
LA LA LA 05
LA LA LA 06
LA LA LA 14
but left alive all other boxes i.e. a box with address LA LA LA 03 would not
be affected.
What happens if the command also has a parameter byte ? For example the
channel enable / disable commands which use their parameter byte as a bit
field to enable / disable a group of 8 channels.
An extension of command compression covers this case, allowing the benefits
of multiple box addresses per command with the flexibility of sending
individual parameters to each box.
07 E9 LA LA LA LA xx CHK is one of the LA specific channel switch on/off
command.
Compressed we get :-
nn E9 LA LA LA 04 xx 07 yy 11 zz CHK
where the xx in the command refers to the parameter byte for box with address
LA LA LA 04 and yy refers to a DIFFERENT parameter byte for address LA LA LA
07, finally zz refers to the parameter byte for address LA LA LA 11. So we
have now addressed multiple boxes (up to 64 at once from LA LA LA 00 to LA LA
LA 3F) and sent EACH of them an INDIVIDUAL PARAMETER byte.
In practice ALMOST ALL COMMANDS ARE SENT AS COMMAND COMPRESSION SEQUENCES. In
fact these command compressed channel control commands make up a large
proportion of the overall data channel traffic.
Site Codes:
Because of the constraints of the address format i.e. first byte fixed at E0,
2nd varying from 80 to BF, 3rd from 40 to 7F, and the last from 00 to 3F,
which leaves only 262144 useable addresses. The probability of two cable
systems having active addresses which are the same as another is very likely.
This caused the problem that a box from one system could "migrate" to another
system. Losing firstly Cable Company A's box, and secondly Cable Company B's
revenue.
The solution to this was the SITE CODE. Each cable company was allocated a
unique site code. This is loaded into the box at boot time when the address
is assigned. The head end controller then sticks this site code into the data
stream at every opportunity. If a box sees a site code which does not equal
the one loaded into it, then it will shutdown with an E8 error ( You can
check the error status by pressing F then 0 on the keypad or remote - the
error code is then displayed on the LED display, E0 is the normal error code
for a happy box). The site code is specified as a 4 byte string the same
length as the address. Like the address it has severe formatting constraints.
The default site code is D8 D0 C8 C0, apparently can range up to DF D7 CF C7.
However as is becoming increasingly familiar with this system even the
security mechanisms which were designed in are not used correctly. Over half
of the cable systems I have seen leave the site code as the default allowing
people to move boxes between the systems.
The site code is sent embedded into many global and specific commands.
For example
06 F9 LA LA LA LA CHK is the reset disconnect command.
0A F9 SI TE CO DE LA LA LA LA CHK is the same command with exactly the
^^-^^-^^-^^
These are the 4 bytes of the SITE CODE.
same function but also now containing the site code.
The time set function and channel name commands are also considered by the
head end controller as prime candidates to carry the sitecode.
0C 60 FD 60 0F 02 13 01 15 D8 D0 C8 C0 CHK is the TIME SET command
^^-^^-^^-^^ SITE CODE
seen here with an embedded site code.
The identical unmolested version would be :-
09 60 FD 60 0F 02 13 01 15 CHK
02 = MONTH(STARTS AT 0)
13=DAY (STARTS AT 0)(HEX)
01=HOURS
15=MIN
The rest of the parameters of this command are shown above.
A lot of cubes and testchips also use the sitecode to their own ends. Seeing
as the site code is designed to prevent box migration the designers of test
chips and cubes thought that this was a great idea ! Get the testchip or cube
to load in a Site Code specific to the cube brand, then if the user ever
tried to remove it again and put the box back on the original system the site
codes would mismatch and kill the box. This also stopped people buying one
cube and using it on multiple boxes in their house, once the cube was
installed it was going to stay or else !
How to defeat the site code (on systems that bother to implement it
correctly) :
Site codes have historically caused major problems for testchips and to a
lesser extent cubes. The problem comes when the testchip has to allow the
original data stream through to the box to let multimode commands get though.
The testchip has loaded in its own site code to the box, and the data stream
from the head end has a different site code - result : problems. The
traditional solution to this is just to let the box get killed by site code
errors but continously reload it so that the user only sees a short
interruption.
The very simple solution that we use in our designs is simply to REMOVE the
site code from the box. Yes, due to yet another screw up you can load NO SITE
CODE into the box and it works just fine and TOTALLY IGNORES ANY SITECODE
FROM THE CABLE HEAD END CONTROLLER.
Most test chips (and cable head ends when they boot a box) will load in
the site code along with the Address as follows :-
10 FD 5F LA LA LA LA SN SN SN SN SN SI TE CO DE CHK
<command>< Address ><Serial number><Site Code><checksum>
As covered earlier FD 5F is the load address from serial number command,
it ALSO LOADS IN THE SITE CODE.
As we have just seen earlier the commands work just as well with the site
code removed, except if you REMOVE THE SITE CODE AT ADDRESS LOAD TIME, then
the box will forget about checking it in future commands completely.
So our cleansed load address command now becomes :-
0C FD 5F LA LA LA LA SN SN SN SN SN CHK
<command>< Address ><Serial number><checksum>
This is the exact command we use in our testchips to deal permanently with
the Site Code problem.
We would appreciate any feedback from readers to give us an indication of
where to go from here, whether we need to clarify / go back over things. What
we are doing right and wrong and most importantly what YOU would like to see.
If anyone else wishes to contribute then please do, we will include sections
written by others with or without due credit :)
John
& Ben.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum