Welcome to GOFASTMOTORSPORTS.com ... ... ... Green Flag - Green Flag - Go Go Go ... ... Brought to you by Ricks Satellite - Where the Big Dish Rules!

Ricks Satellite Wildfeed and Backhaul Forum
Register Latest Topics
 
 
 


Reply
  Author   Comment   Page 4 of 7      Prev   1   2   3   4   5   6   7   Next
pendragon

Registered:
Posts: 1,038
Reply with quote  #46 
Looking at stv090x.c and saa716x_ff_main.c, it appears you should set diseqc_mode to 2 (STV0900_DISEQC_2_3_PWM). If that doesn't work, we should check the various tuner and demod oscillator settings.
Richard

Registered:
Posts: 64
Reply with quote  #47 
Hi Pendragon,

Thanks again. This mode change seemed to make no real difference, so I reverted it and started playing with the oscillator settings.

I ended up changing .xtal from 13500000 to 27000000 and things started locking, but with incorrect reported SR, so then I also removed the tun*_clkdiv settings as well, which gave reliable, fast locks and correct reports.

After then trying a few other combinations, I came back to the above, but it's now no longer locking again. I've obviously broken something, but have run out of time to pursue further. I am perplexed by that change in  .xtal value though, in the context of the original saa716x_ff_main.c stv090x_attach function.

Will carry on at the weekend.

Regards,

Richard
pendragon

Registered:
Posts: 1,038
Reply with quote  #48 
This is a bit weird, and perhaps my copies of saa716x_ff_main.c, stv6110.c, and stv090x.c are not the same as yours. In my copy of saa716x_ff_main.c I have the following inside tt6400_stv090x_config:

.xtal= 13500000,


and the following inside tt6400_stv6110x_config:

.refclk= 27000000,
.clk_div= 2,

The last two specify a crystal frequency of 27 MHz driving the STV6110 tuners, which is standard, and a output clock divider of 2^2 = 4 from the tuner. The relevant line in stv6110.c for stv6110_init is:

priv->regs[RSTV6110_CTRL2] |= (priv->clk_div << 6);

My understanding of the STV6110 is this will make the output frequency to the demod 27 / 4 = 6.75 MHz. But tt6400_stv090x_config has a setting of 13.5 MHz. On the surface this may just be a simple programming error that was later corrected, ie. they should have .clk_div= 1 in tt6400_stv6110x_config, because 2^1 = 2. Or maybe it works by some accident with stv090x.c.

However STM preferred the STV090* demods to be driven with a 27 MHz clock, and this is the combination that worked for you with the stv0900 driver. Setting tun*_clkdiv to either 0 or 1 should cause the STV6110 to pass through its crystal frequency unaltered (27 MHz), which means you have to set the following in tt6400_stv0900_config:

.xtal = 27000000,

which is what you did. I believe you are on the correct track with these settings. I still believe you should have .diseqc_mode = 2, or as a last resort 4, but if 0 instead works, I'm not sure why.

crazycat

Avatar / Picture

Registered:
Posts: 1,054
Reply with quote  #49 
135Mhz is internal clock for stv090x demod.
__________________
Strong offset dish 0.95m on Powertech DG240 motor + ALPS BSTE8-751B Ku-Universal LNB. Variant CA-902 0.95 offset dish with 3xDreamSat DS-8 Ku-Universal LNBs (13E+4.8E+4W) + Variant CA-600 Ku-Circular LNB 36E + DiseqC 1.0. STB: GI8120 Lite. PC DVB: Omicom S2 PCI; TBS 6983 PCI; TBS QBox-CI USB(5980), 5927.
Richard

Registered:
Posts: 64
Reply with quote  #50 
Quote:
Originally Posted by pendragon
This is a bit weird, and perhaps my copies of saa716x_ff_main.c, stv6110.c, and stv090x.c are not the same as yours. In my copy of saa716x_ff_main.c I have the following inside tt6400_stv090x_config:

.xtal= 13500000,


and the following inside tt6400_stv6110x_config:

.refclk= 27000000,
.clk_div= 2,



Yes, you have the same files as me although in the case of the original stv090x setup, TT are using stv6110x, not stv6110 as the tuner driver.

Quote:
Originally Posted by pendragon


The last two specify a crystal frequency of 27 MHz driving the STV6110 tuners, which is standard, and a output clock divider of 2^2 = 4 from the tuner. The relevant line in stv6110.c for stv6110_init is:

priv->regs[RSTV6110_CTRL2] |= (priv->clk_div << 6);

My understanding of the STV6110 is this will make the output frequency to the demod 27 / 4 = 6.75 MHz. But tt6400_stv090x_config has a setting of 13.5 MHz. On the surface this may just be a simple programming error that was later corrected, ie. they should have .clk_div= 1 in tt6400_stv6110x_config, because 2^1 = 2. Or maybe it works by some accident with stv090x.c.

However STM preferred the STV090* demods to be driven with a 27 MHz clock, and this is the combination that worked for you with the stv0900 driver. Setting tun*_clkdiv to either 0 or 1 should cause the STV6110 to pass through its crystal frequency unaltered (27 MHz), which means you have to set the following in tt6400_stv0900_config:

.xtal = 27000000,

which is what you did. I believe you are on the correct track with these settings. I still believe you should have .diseqc_mode = 2, or as a last resort 4, but if 0 instead works, I'm not sure why.



Your confusion reflects mine, hence why I tried tinkering with the .xtal value.

Re. the diseqc mode, I had the thought that as the 22kHz clock is derived from the above, having the wrong values may put this too far off frequency to register at the switch.

All that said, with .xtal= 13500000, the log output from your driver still showed mclk as 135000000, which is the value I'd expect.

I'll be able to get stuck in again  tomorrow (1730 NZST currently), to find out more.

Regards,

Richard
Richard

Registered:
Posts: 64
Reply with quote  #51 
Quote:
Originally Posted by crazycat
135Mhz is internal clock for stv090x demod.


Hi crazycat,

Thanks you're right and for a while I read the value in the saa716x_ff_main.c tt6400_stv090x_config function as 135MHz, .xtal is actually defined as 13.5MHz.
pendragon

Registered:
Posts: 1,038
Reply with quote  #52 
Quote:
Originally Posted by Richard

Yes, you have the same files as me although in the case of the original stv090x setup, TT are using stv6110x, not stv6110 as the tuner driver.


That solves most of the mystery, because in stv6110x.c, clk_div=2 means the clock divider output is 2. stv6110.c has a different convention.

I'm still not entirely sure why they would have the tuner divide the 27 MHz clock in the first place for a STV090* demod, which was designed to work best with a 27 MHz clock. Early versions of the STV6110 tuners had mediocre CNR performance when using a unity divider because they converted the clock to a square wave on the output. Later versions were improved by having the tuner pass through the sine wave to the output for a unity divider setting. I was never able to determine whether CNR is compromised for non-unity divider settings, because those always produce square wave outputs. 

What is clear is the stv0900_core.c code does not handle non-unity dividers correctly. I would suggest changing the stv0900_hard_reset function where it reads:

Code:
chip->quartz = config->xtal;

to:

Code:
chip->quartz = config->tun1_clkdiv < 2 ? config->xtal : config->xtal / config->tun1_clkdiv;

This should allow you to use either tun*_clkdiv = 1 or 2 in your configuration settings. I would suggest starting with 1, and only change to 2 if the CNR results are bad with 1. Of course you should now always use xtal = 27000000 because that is the crystal frequency for the tuner.

Richard

Registered:
Posts: 64
Reply with quote  #53 
Quote:
Originally Posted by pendragon


That solves most of the mystery, because in stv6110x.c, clk_div=2 means the clock divider output is 2. stv6110.c has a different convention.



That was the conclusion I came to last night also and clk_div=1 was going to be the next thing to try.

Will have a result later today.
Richard

Registered:
Posts: 64
Reply with quote  #54 
With .xtal = 27000000 and tun*_clkdiv = 1, things are locking reliably:

Code:

tune-s2 12456 H 22500 -adapter 3 -committed 1 -lnb UNIVERSAL
LNB: low: 9750 high: 10600 switch: 11700
opening: /dev/dvb/adapter3/frontend0
frontend: (STV0900 frontend)
fmin 940000 MHz
fmax 2160000 MHz
min_sr 100 Ksps
max_sr 60000 Ksps
HIGH band
22khz ON
DiSEqC: e0 10 38 f0 00 00 length: 4

Tuning specs:
System:     DVB-S
Frequency:  12456000 H 22500
22khz:      ON
Modulation: QPSK
FEC:        AUTO
Inversion:  AUTO
Rolloff:    AUTO
Pilot:      AUTO
MIS:        -1

Tuned specs:
System:     DVB-S 5
Frequency:  1867900 H 22500
22khz:      ON
Modulation: QPSK 0
FEC:        3/4 7
Inversion:  ON 1
Rolloff:    35 0
Pilot:      ON 1
MIS:        -1
FRAME_LEN:  LONG 0
Bandwidth:  30.3750 MHz
Data Rate:  31.1029 Mbps
CN Failure: 7.2 dB

status Locked | signal 96.4 % | snr 366.1 dB | ber 0 | FE_HAS_LOCK


Code:
 
[ 1218.538843] stv0900_init
[ 1218.538852] stv0900_wakeup
[ 1218.546598] stv0900_hard_reset
[ 1218.547376] stv0900_initialize chip_id 0x20 errs 0
[ 1218.668592] stv0900_set_mclk: Mclk set to 135000000, Quartz = 27000000
[ 1218.682853] stv0900_set_ts_parallel_serial path1 2 path2 2
[ 1218.902850] stv0900_algo
[ 1218.906485] stv0900_set_tuner: freq 1856000000 bw 30375000
[ 1218.912117] stv0900_wait_tuner: time 2
[ 1218.914624] stv0900_set_search_standard: DVB-S
[ 1218.919757] stv0900_set_viterbi_standard: ViterbiStandard DVB-S
[ 1218.927057] stv0900_set_symbol_rate: sr 1000000
[ 1218.936040] stv0900_blind_check_agc2_min_level: status 0 step 0 min 30d th af0
[ 1218.936057] stv0900_set_symbol_rate: sr 22500000
[ 1218.940561] stv0900_blind_search_algo: step 0 k_ref_tmg 80 pass 0
[ 1219.026603] coarse: time 13 start 0 cf 9305 356300 sr 21304893 442563 timing 10 agc2 1432
[ 1219.032758] fine: freq 1855995634 sr 21304893 min 14913425 max 27696360
[ 1219.057253] DEMOD LOCK OK time 20
[ 1219.097884] stv0900_get_signal_params: range 12 freq 1856660394 offset 674065 sr 22499844 modcode 7 rolloff 0 pilot 0 frame 0
[ 1219.097892] stv0900_algo
[ 1219.103392] stv0900_set_tuner: freq 1856660394 bw 35374789
[ 1219.109091] stv0900_wait_tuner: time 2
[ 1219.112141] stv0900_set_search_standard: DVB-S
[ 1219.117418] stv0900_set_viterbi_standard: ViterbiStandard DVB-S
[ 1219.154018] DEMOD LOCK OK time 20
[ 1219.166609] stv0900_get_signal_params: range 12 freq 1857300907 offset 681766 sr 22500174 modcode 7 rolloff 0 pilot 0 frame 0
[ 1219.166626] stv0900_track_optimization: found DVB-S or DSS
[ 1219.173849] DEMOD LOCK OK time 0
[ 1219.174963] FEC   LOCK OK state 3 time 0 timeout 152
[ 1219.175603] stv0900_wait_for_lock: OK timer 0 timeout 152
[ 1219.177906] FULL LOCK 9f
[ 1219.215573] Result 12 freq 1857300907 sr 22500174
[ 1219.215579] Search Success


I have still to address tune-s2's STR and SNR handling.

The diseqc mode does not seem to affect things - 0 or 2 result in correct switching to ports 1 and 2 on the 4x1, but neither work with port 3. That is a mystery I'll pursue later.

Many thanks for persisting with me. I'm learning a great deal and look forward to finding out more.

Regards,

Richard
midwestmac

Registered:
Posts: 2,290
Reply with quote  #55 
I took down the blindscan-s2 app from bibucket a week ago  to get rid of some ioctl calls.

@ Richard as for the Tune-s2 app. I cant get the ber to report right. or the read status "lock" "unlocked"
Under the int tune .cmd = DTV_STREAM_ID might be my read status problem I don't know? Thats what I used
UDL uses the .cmd = DTV_DVBS2_MIS_ID
Or maybe I broke something else?
I'm still playing with it when I have time.
If you want permission to the bitbucket V4l-pendragon I'll set you up with that?

But here's what I have for signal and snr, let me know whats wrong.
edit: wrong with this... if anything.
Code:

  lvl_scale = p_status.props[0].u.st.stat[0].scale;
  if (lvl_scale == FE_SCALE_DECIBEL) {
                 lvl = p_status.props[0].u.sdata / 1024.0;
  } else {
    int lvl2;
    if (ioctl(frontend_fd, FE_READ_SIGNAL_STRENGTH, &lvl2) == -1) {
      lvl = 0;
    } else {
                          lvl = (float)lvl2 / 1024.0;
      if (lvl < 0) {
        lvl = 0;
                       }
                }
        }
       snr_scale = p_status.props[1].u.st.stat[0].scale;
  if (snr_scale == FE_SCALE_DECIBEL) {
     snr = p_status.props[1].u.sdata / 1024.0;
  } else {
    unsigned int snr2 = 0;
    if (ioctl(frontend_fd, FE_READ_SNR, &snr2) == -1) {
      snr2 = 0;
    }
                  snr = (float)snr2 / 0xff;
  }



then I have
Code:

printf ("status %s | signal %5.1f dBm | snr %5.1f dB | ber %u| ", 

instead of
Code:

printf ("status %s | signal %2.1f %s | snr %2.1f dB | ber %u | ",




__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q
Richard

Registered:
Posts: 64
Reply with quote  #56 
Hi,

Quote:
Originally Posted by midwestmac


@ Richard as for the Tune-s2 app. I cant get the ber to report right. or the read status "lock" "unlocked"
Under the int tune .cmd = DTV_STREAM_ID might be my read status problem I don't know? Thats what I used
UDL uses the .cmd = DTV_DVBS2_MIS_ID
Or maybe I broke something else?
I'm still playing with it when I have time.



I checked out updatelee's current tune-s2 and the only changes I've made to this point, was to change this:

Code:

 { .cmd = DTV_FREQUENCY,                 .u.data = t->freq * 1000 },

to

 { .cmd = DTV_FREQUENCY,                 .u.data64 = t->freq * 1000L },

this:
Code:

printf("Frequency:  %d %s %d \n", abs(p_tune[1].u.data/1000 + t->LO), value2name(p_tune[2].u.data, dvb_voltage) , p_tune[3].u.data / 1000);

to

printf("Frequency:  %d %s %d \n", abs(p_tune[1].u.data64/1000L + (t->LO * 1000)), value2name(p_tune[2].u.data, dvb_voltage) , p_tune[3].u.data / 1000);

EDIT: just realised this change ( * 1000) is redundent  and explains the extra trailing zeros I'm seeing.


comment out the two instances of:
Code:

//              if (ioctl(frontend_fd, FE_READ_STATUS, &status) == -1) {
//                      perror("FE_READ_STATUS failed");
//              }

and add " * 1000" to the end of this portion of code, as I use universal LNBs:

Code:

        if (lnb.threshold && lnb.high && t.freq > lnb.threshold)
        {
                printf("HIGH band\n");
                t.tone = SEC_TONE_ON;
                t.LO = lnb.high;
                t.freq = abs((t.freq - abs(t.LO)) * 1000);


so not sure what change you've made that might be causing the lack of lock.

I'm in the very early stages of teaching myself C and am using this as an exercise in trying to work stuff out as I go.

Quote:
Originally Posted by midwestmac

If you want permission to the bitbucket V4l-pendragon I'll set you up with that?

Thanks. When I'm halfway confident I have something solid to contribute, I'll let you know [smile]
In the meantime, I'll post anything useful I work out around tune-s2.

Quote:
Originally Posted by midwestmac

But here's what I have for signal and snr, let me know whats wrong.
edit: wrong with this... if anything.
Code:
 lvl_scale = p_status.props[0].u.st.stat[0].scale; if (lvl_scale == FE_SCALE_DECIBEL) { lvl = p_status.props[0].u.sdata / 1024.0; } else { int lvl2; if (ioctl(frontend_fd, FE_READ_SIGNAL_STRENGTH, &lvl2) == -1) { lvl = 0; } else { lvl = (float)lvl2 / 1024.0; if (lvl < 0) { lvl = 0; } } } snr_scale = p_status.props[1].u.st.stat[0].scale; if (snr_scale == FE_SCALE_DECIBEL) { snr = p_status.props[1].u.sdata / 1024.0; } else { unsigned int snr2 = 0; if (ioctl(frontend_fd, FE_READ_SNR, &snr2) == -1) { snr2 = 0; } snr = (float)snr2 / 0xff; } 


then I have
Code:
 printf ("status %s | signal %5.1f dBm | snr %5.1f dB | ber %u| ", 

instead of
Code:
 printf ("status %s | signal %2.1f %s | snr %2.1f dB | ber %u | ", 



Thanks, I'll refer back to this if I can't stumble my way through to a solution on my own.

Regards,

Richard
midwestmac

Registered:
Posts: 2,290
Reply with quote  #57 
Ok. thanks for the info.  I can get a Lock on everything I should.
I just get an output like this. Even though it is locked

Tuned specs:
System:     DVB-S 5
Frequency:  11782 H 20760
22khz:      ON
Modulation: QPSK 0
FEC:        3/4 7
Inversion:  ON 1
Rolloff:    35 0
Pilot:      ON 1
MIS:        -1
FRAME_LEN:  LONG 0
Bandwidth:  28.0260 MHz
Data Rate:  28.6976 Mbps
CN Failure: 7.2 dB

status Unlocked | signal 789938.5  dBm| snr 13.4 dB | ber 4210155 |
status Unlocked | signal 50.5  dBm| snr 13.5 dB | ber 4210155 |
status Unlocked | signal 50.5  dBm| snr 13.4 dB | ber 4210155 |



So disregard what I posted above. I haven't figured this  out yet

__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q
midwestmac

Registered:
Posts: 2,290
Reply with quote  #58 
Richard I'm teaching myself too. I think I almost have tune-s2 working right Under
int check_frontend
struct dtv_property p
I added  p[3].cmd = DTV_STATUS;
and
status = p_status.props[3].u.sdata;

because I had no info on the status for this printf line
Code:

printf ("status %s | signal %2.3f dBm| snr %2.3f dB | ",
(status & FE_HAS_LOCK) ? "Locked" : "Unlocked", lvl,(lvl_scale == FE_SCALE_DECIBEL) ? "dBm" : "%", snr);
printf ("ber %u |" ,ber);


Also
Code:

 { .cmd = DTV_FREQUENCY,                 .u.data64 = t->freq * 1000L },

change to
Code:

{ .cmd = DTV_FREQUENCY,      .u.data64 = t->freq * 1000000L }

changed this too
Code:

printf("Frequency:  %d %s %d \n", abs(p_tune[1].u.data/1000000  + t->LO), value2name(p_tune[2].u.data, dvb_voltage) , p_tune[3].u.data / 1000);

and this too
Code:

printf("Frequency:  %d %s %d \n", abs(p_status.props[1].u.data/1000000 + t->LO), value2name(p_status.props[2].u.data, dvb_voltage) , p_status.props[3].u.data / 1000);


I tried the adding 
Code:

t.freq = abs((t.freq - abs(t.LO)) * 1000);


And that worked, but for me it didn't want to  tune below 11700, I have a Universal lnb also. Now I need to find a signal below 11700
The read status errors below I haven't committed that out yet I have it set to do that 2 times
And I don't think the frame_length is reported right for,, short frames if thats possible.


Code:

tune-s2 $ ./tune-s2 11882 V 30000 -lnb UNIVERSAL
LNB: low: 9750 high: 10600 switch: 11700 
opening: /dev/dvb/adapter0/frontend0
frontend: (STV0900 frontend) 
fmin 940000 MHz 
fmax 2160000 MHz 
min_sr 100 Ksps
max_sr 60000 Ksps
HIGH band
22khz ON
Tuning specs: 
System:     DVB-S 
Frequency:  11882 V 30000 
22khz:      ON 
Modulation: QPSK 
FEC:        AUTO 
Inversion:  AUTO 
Rolloff:    AUTO 
Pilot:      AUTO 
MIS:        -1 
FE_READ_STATUS failed: Operation not supported
FE_READ_STATUS failed: Operation not supported
Tuned specs: 
System:     DVB-S 5 
Frequency:  11882 V 29998 
22khz:      ON 
Modulation: QPSK 0 
FEC:        3/4 7 
Inversion:  ON 1 
Rolloff:    35 0 
Pilot:      OFF 1 
MIS:        -1 
FRAME_LEN:  LONG 0 
Bandwidth:  40.4973 MHz 
Data Rate:  41.4678 Mbps 
CN Failure: 7.2 dB 
status Locked | signal 50.650 dBm| snr 12.325 dB | ber 0 | FE_HAS_LOCK 
status Locked | signal 50.647 dBm| snr 12.373 dB | ber 0 | FE_HAS_LOCK 
status Locked | signal 50.650 dBm| snr 12.369 dB | ber 0 | FE_HAS_LOCK 





__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q
Richard

Registered:
Posts: 64
Reply with quote  #59 
Thanks.

I did the same as you last night regarding DTV_STATUS, but it caused some unexpected things to happen, but then I've applied some other changes too.

Am not able to spend much time playing at the moment, as this system is my production PVR and I have to swap cables.

Will get a splitter, which'll make life easier.
pendragon

Registered:
Posts: 1,038
Reply with quote  #60 
A few points on first look:

The DVB infrastructure in Linux is the perfect illustration of the comment sometimes attributed to Grace Hopper: "I love standards. There are so many to choose from". When it comes to measurements as signal level and CNR, Linux offers countless ways to fetch them in all sorts of representations and scaling using the old legacy ioctls and the more recent S2API (even that has alternate names, for confusion's sake). Nearly every driver has its own convention.

Back in 2009 I had no interest in supporting the misguided and often meaningless schemes that non-engineers had implemented. So I chose signed dB/dBm in units of 1/1024 of a dB for all the drivers I wrote/modified. Much easier to calculate in a driver (where Torvalds can't stomach the utility of floating point), and arguably faster floating point conversion in the application. My recollection is my code supported the legacy ioctls, along with the preferred S2API.

Years later the whole situation devolved further with the introduction of the DTV_STAT_* and FE_SCALE_* constructs on top of what was already there. A point solution for an overflowing bathtub, when the whole village was flooded. Did anyone seriously believe driver writers were going to code support for every possible form of interrogating these quantities? Of course the folks who devised this spent no time adding any driver support for their new shiny object. Thus every existing driver continued to provide whatever it did in the past, and occasionally newer drivers chose to handle DTV_STAT_*.

I saw no point in supporting this train wreck. It defined yet another representation (units of 0.001 dB) that was more painful to calculate in a driver, failed to address the systemic problem of units and scaling, and continued the moronic percentage "scale". So either don't test for FE_SCALE_DECIBEL with my drivers, or add the code to support DTV_STAT_* in the drivers. Also if you're conditionally calling the FE_READ_SIGNAL_STRENGTH and FE_READ_SNR ioctls for my drivers, you're just wasting CPU and clock time. The S2API approach is more efficient and less ambiguous.

The signal level should always come back as negative dBm. If it comes as positive, something is wrong.

I'm not sure what the problem is with DTV_STATUS. Perhaps there is a disconnect between frontend.h in the kernel/driver builds and the application. As an aside, parameters such as DTV_STATUS, DTV_FREQUENCY, DTV_CNR, and DTV_SIGNAL_LEVEL return values from the parameter cache. This is fast, but the values are from when the driver last updated them, which could be when the last tuning command was sent. If you want up-to-date values, use parameters such as DTV_UPDATE_STATUS, DTV_UPDATE_FREQUENCY, DTV_UPDATE_CNR, and DTV_UPDATE_SIGNAL_LEVEL. These will take longer because the driver has to interrogate the demod hardware.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.

Fellow Members, your posts are welcome here! Do not worry about posting everything perfect. Different receivers and LNB's will give you different Frequencies and Symbol Rates. Some set top boxes, PCI cards and USB receivers, Do Not Require all of the same information that others may need. It is not Required to post everything that others may need to tune in a feed. It is just most important to share the find. We can always adjust the Frequency and Symbol Rates and try the various Modulations and FEC's on our own receivers until we get a lock and then give a polite reply with what works for your receiver, as that information might help others as well. We all appreciate the efforts and energy of the Posters!

Thank You for Visiting GOFASTMOTORSPORTS.com - Keep Your Eyes on the Sky and the Track!