iDirect TAC Tips – Information on Fast Fade Corr, CRC8/CRC32 errors and NCR lock lost counters

Information on Fast Fade Corr, CRC8/CRC32 errors and NCR lock lost counters

“Fast Fade Corr” stands for “fast fade correction” and is the number of times the remote was detected (by the hub) as going into a fast fade condition. A fast fade condition is where the remote’s reported Downstream SNR drops more than a certain amount in a certain period of time. When this is detected, the system drops the MODCOD of the remote (assuming DVB-S2 ACM mode here) way more than a normal adjustment, to try and compensate for the sudden drop in signal strength, hence keeping remote from dropping out of the network. You can read more in iBuilder User guide under section “5.12 DVB-S2 Network Parameters”, that is where you can learn how to adjust these.

What are CRC8/CRC32 errors?

In DVB-S2 carriers, the classic “SCPC errors” don’t exist. In DVB-S2, these have been replaced by CRC8 and CRC32 errors.

Below is a description of how they work.

The basic building block of the DVB carrier is called the BaseBand Frame (BBFrame). CRC8 and CRC32 errors will provide two separate levels of error checking, each is responsible for different segments of the BBFrame.

CRC8 error detection occurs on the BBFrame Header. The CRC8 protects the BBFrame header at the beginning of each BBFrame, while CRC32 protects the entire BBFrame. It is fair to say that

CRC32 covers the user data plus the BBFrame header, letting you know if the BBFrame in its entirety is good.

When CRC8 errors occur, the whole frame needs to be discarded at the destination and retransmitted from the source. When you receive a CRC8 error, you shouldn’t receive a CRC32 error for the same frame. CRC8 errors serve to tell the recipient that the BBFrame can’t be trusted, since it’s header can’t be decoded reliably.

CRC32 errors indicate that the BBFrame header is fine, but some part of the user data is not correct. In this case, the backend will see the BBFrame and will record its existence, but will not pass the “suspect” user data out of the modem because it can’t be trusted.

The bottom line is: in both cases the BBFrame is discarded and data retransmission is required.

NCR Lost Lock

The purpose of Network Clock Reference (NCR) delivery is to provide a common clock to all terminals for precision timing on TDMA return link transmissions (including the initial logon burst). The iDirect DVB-S2 system uses NCR to achieve return channel synchronization. The system sends important data at minimum modcod of the Tx carrier. This data includes BTP + NCR Synchronization information.

NCR lost lock means that remote operating in DVBs2 network is able to lock to the Signal but the remote does not get any BTP or data. This could be because the NCR is not locked on the modem, as the modem might be listening to a different beam. If there is an NCR Lost in that case remote can never be able to Transmit.


3 Responses to iDirect TAC Tips – Information on Fast Fade Corr, CRC8/CRC32 errors and NCR lock lost counters

  1. Luis Torrealba says:

    Can anyone give a large or specific explanation of Fast Fade Corr?

    • iDirect says:

      The Fast Fade Corr (correction) is the number of times the remote reported a decrease in the Down C/N since the last reboot.

      The stats increase even if the down C/N decreases 1 db (which is ok), however if stats increase too much, please check the down c/n value as this could indicate that the remote is experiencing bad weather conditions.

  2. Tom francis says:

    What causes CRC8/CRC32 errors ? Why CRC8 error requires RMA ?