Packet losses

[mkv7196]

I recently got a PCI card for my computer and have noticed that during the daytime I get packet losses (maybe 10-100 packets lost every few hours). During the night time it's almost perfect with no packet loss. The signal strength remains high 11-15 dB, yet the packet losses still occur for some reason, leading me to think maybe the dish is collecting some signals other than the currently aimed satellite.

I have a 10ft mesh with a ~ 100ft cable run (rg6). Looking at the attenuation losses rg6 loses about 6 dB at 100ft. Would it be worthwhile to try a 50ft rg6. What kind of difference in signal strength would 3dB instead of 6dB loss make?

Can cell phone towers cause interference with cband? There is a power line tower about 300ft away and it has some communication equipment attached to it (looks like cellphone related).

 

[Titanium]

The signal strength reading that you are referencing is likely the signal level over the noise threshold. Decreasing the coax length by 50' will reduce the attenuation, but it will not increase the SN by 3dB. LNBs and LNBFs provide very high signal amplification and it is very unlikely that the packet loss is due to low IF signal in the distribution.

This amount of data loss over suich a long time is very small and the Forward Error Correction will fill in with the redundant data. You will not observe any reception problems due to this low data loss, only be bothered by the charting. LOL! To put this into perspective, view the total data throughput in an hour and compare to the lost data during the same time-frame. If you are receiving a signal using a very high FEC of 9/10 (requiring 9 out of every 10 bits of data to be received without error), 10% of the data would need to be corrupted before the receiver was unable to decode without defect. Lower FEC ratios will permit even high amounts of corrupt data before the receiver can no longer correct.

The loss of data might be due to errors in the uplink or downlink. It could be losses in the iroinisphere, terrestrial or in LNB downconversion, distribution or demodulation. A site survey with a spectrum analyzer would be able to determine if any terrestrial interference is present. Any type of RF transmission is capable of interference. Sometimes it is a signal colocated on the same frequency and other times it might be a harmonic of a signal transmiotted on a different frequency. Could a cell phone signmal cause interefernce? Yes, but unlikely. Could a powerline cause intereference? Yes, but unlikely. Could an arcing switch, failing transformer, desktop computer, WiFi/hotspot, microwave, florescent/CLF/LED light or a myriad of other appliances and electronic devices cause interference? Yes, very possible!

 

[mkv7196]

I believe these packet losses are actually corrupted data after FEC is done. In dvbdream there's a packet loss counter that shows the # of bad packets based on the continuity counter field of a transport stream. This field increments by one for each packet and if this field doesn't do that it means that packet is bad (example Discontinuity, expected=9, found=11 in the log below).

This is an example recording of NBC on 105w that uses FEC 3/4. There are 63 bad packets in this 25 minute recording. If I go to 15mins 26seconds where the log below shows the bad packets there is actually unwatchable video there (pixelated, garbled sound, etc).

Do you have some other software that shows raw packet errors prior to error correction being done?

## File = D:\20170123_205058 Ch 9 NBC EAST.ts
    Included PIDs (*=PCR)    =    264, 517*, 751, 752, 753, 754
    Root PIDs found    =    0
    First and last PCR    =    04:08:41.3, 04:34:05.0  (in pid #517)
    Duration        =    00:25:23.7
---------------------------------------------------------------------------------------------------
Checking in progress
@00:15:26.2 (pid=517):    Error flag set
@00:15:26.2 (pid=517):    Discontinuity, expected=9, found=11
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=14
@00:15:26.2 (pid=517):    Discontinuity, expected=15, found=7
@00:15:26.2 (pid=517):    Discontinuity, expected=14, found=6
@00:15:26.2 (pid=753):    Discontinuity, expected=15, found=0
@00:15:26.2 (pid=751):    Discontinuity, expected=0, found=1
@00:15:26.2 (pid=517):    Discontinuity, expected=8, found=9
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=13
@00:15:26.2 (pid=517):    Discontinuity, expected=14, found=7
@00:15:26.2 (pid=753):    Discontinuity, expected=4, found=7
@00:15:26.2 (pid=754):    Discontinuity, expected=4, found=7
@00:15:26.2 (pid=751):    Discontinuity, expected=4, found=8
@00:15:26.2 (pid=752):    Discontinuity, expected=4, found=8
@00:15:26.2 (pid=517):    Discontinuity, expected=10, found=11
@00:15:26.2 (pid=752):    Discontinuity, expected=9, found=11
@00:15:26.2 (pid=517):    Discontinuity, expected=13, found=1
@00:15:26.2 (pid=753):    Discontinuity, expected=8, found=11
@00:15:26.2 (pid=754):    Discontinuity, expected=8, found=11
@00:15:26.2 (pid=751):    Discontinuity, expected=9, found=12
@00:15:26.2 (pid=517):    Discontinuity, expected=15, found=2
@00:15:26.2 (pid=754):    Discontinuity, expected=13, found=15
@00:15:26.2 (pid=751):    Discontinuity, expected=13, found=0
@00:15:26.2 (pid=752):    Discontinuity, expected=13, found=0
@00:15:26.2 (pid=753):    Discontinuity, expected=13, found=0
@00:15:26.2 (pid=517):    Discontinuity, expected=1, found=6
@00:15:26.2 (pid=517):    Discontinuity, expected=8, found=9
@00:15:26.2 (pid=751):    Discontinuity, expected=2, found=5
@00:15:26.2 (pid=752):    Discontinuity, expected=1, found=5
@00:15:26.2 (pid=753):    Discontinuity, expected=1, found=5
@00:15:26.2 (pid=517):    Discontinuity, expected=3, found=7
@00:15:26.2 (pid=517):    Discontinuity, expected=9, found=12
@00:15:26.2 (pid=752):    Discontinuity, expected=6, found=8
@00:15:26.2 (pid=753):    Discontinuity, expected=6, found=8
@00:15:26.2 (pid=754):    Discontinuity, expected=1, found=8
@00:15:26.2 (pid=751):    Discontinuity, expected=6, found=9
@00:15:26.2 (pid=517):    Discontinuity, expected=4, found=5
@00:15:26.2 (pid=517):    Discontinuity, expected=6, found=7
@00:15:26.2 (pid=517):    Discontinuity, expected=9, found=11
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=7
@00:15:26.2 (pid=751):    Discontinuity, expected=11, found=14
@00:15:26.2 (pid=752):    Discontinuity, expected=10, found=14
@00:15:26.2 (pid=753):    Discontinuity, expected=11, found=14
@00:15:26.2 (pid=264):    Discontinuity, expected=3, found=4
@00:15:26.2 (pid=754):    Discontinuity, expected=10, found=14
@00:15:26.2 (pid=517):    Discontinuity, expected=4, found=5
@00:15:26.2 (pid=517):    Discontinuity, expected=6, found=9
@00:15:26.2 (pid=517):    Discontinuity, expected=10, found=11
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=8
@00:15:26.2 (pid=517):    Discontinuity, expected=9, found=11
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=4
@00:15:26.2 (pid=517):    Discontinuity, expected=12, found=4
@00:15:26.2 (pid=754):    Discontinuity, expected=2, found=3
@00:15:26.2 (pid=517):    Discontinuity, expected=11, found=3
@00:15:26.2 (pid=751):    Discontinuity, expected=3, found=4
@00:15:26.4 (pid=753):    Discontinuity, expected=3, found=4
@22:02:57.5 (pid=517):    Discontinuity, expected=5, found=9
@22:02:57.5 (pid=517):    Discontinuity, expected=10, found=5
@22:02:57.5 (pid=517):    Discontinuity, expected=12, found=5
@22:02:57.5 (pid=754):    Discontinuity, expected=11, found=12
@22:02:57.5 (pid=751):    Discontinuity, expected=12, found=13
@22:02:57.5 (pid=517):    Discontinuity, expected=12, found=4
@00:15:26.4 (pid=753):    Discontinuity, expected=11, found=13
Done.
Error report for this file:
    Packet count    =    17055491
    Continuity errors    =    62
    Error flag set    =    1
    Packets with error    =    63

 

[Titanium]

I primarily use EBSpro and TSReader. Loaded DVBDream years ago, but used only a few times as I found it to be quite buggy and did not enjoy the experience.

The majority of packet losses in your example occurred in within a second. Without comparing the downlink data to the recorded TS, it would be impossible to determine where in the process the loss of data originated. Studying a recorded TS file playout adds even more possibilities for the introduction of errors. Added to the up/down/conversion/distribution/demod... could be a buffering, network, local file error, etc.

 

[mkv7196]

I tried tsreader and it looks like the uncorrectable 'TEI errors' in it corresponds to the packet losses counter in dvbdream. I don't have a spectrum analyzer to look for terrestrial interference. Would something like the rf scanner in ebspro work as a substitute? I think even with an actual spectrum analyzer it might be difficult to pinpoint where the interference is coming from since the packet losses happen for just a second or so.

 

[Titanium]

I agree that a spectrum analyzer will may not detect momentary source of interference if it is confined to specific frequency. If it is a broad spectrum interference, it would be easier to detect. The RF scanner feature may work, but the sample rate may be too low to capture these short duration events.

The time charting monitor SNR and BER of the affected transponder(s) may reveal a timing sequence.

Questions that might assist in narrowing the search: Is this loss occurring with specific or random timing? Is it affecting multiple transponder frequencies. Is it affecting transponders on one or both polarities? Is it noted on similar transponders on adjacent satellites? Is it occurring on multiple tuners or only with the card?