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 5 of 5     «   Prev   2   3   4   5
Richard

Registered:
Posts: 58
Reply with quote  #61 
Quote:
Originally Posted by pendragon
A few points on first look:
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.


Yes, I had wondered myself, at the options around this. Good I guess from the point of view of giving people options to fall back on, but only if legacy driver authors update their code.

I chose to comment out all the testing for scale etc, and used DTV_SIGNAL_LEVEL and DTV_CNR, but although I am using this:

snr = p_status.props[1].u.st.stat[0].svalue / 1024;

the result I get seems to be 100 x too large. I am wondering if this part "stat[0].svalue" is not correct in this circumstance.

Quote:
Originally Posted by pendragon

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.


Thanks, I'd figured out the first part, but thought that the *_UPDATE_* parameters just updated the cache, not returned the values as well.
pendragon

Registered:
Posts: 1,017
Reply with quote  #62 
Quote:
Originally Posted by Richard
I chose to comment out all the testing for scale etc, and used DTV_SIGNAL_LEVEL and DTV_CNR, but although I am using this:

snr = p_status.props[1].u.st.stat[0].svalue / 1024;

the result I get seems to be 100 x too large. I am wondering if this part "stat[0].svalue" is not correct in this circumstance.


My drivers don't fill struct dtv_fe_stats. Try this for both signal level and CNR:

snr = p_status.props[1].u.sdata / 1024.0;
Richard

Registered:
Posts: 58
Reply with quote  #63 
Quote:
Originally Posted by pendragon


My drivers don't fill struct dtv_fe_stats. Try this for both signal level and CNR:

snr = p_status.props[1].u.sdata / 1024.0;


Very timely, as I've spent the last hour on this and gotten to:

snr = p_status.props[1].u.data / 1024

So now I think I'm good, although signal level seems a bit high:

Code:

Tuned specs:
System:     DVB-S 5
Frequency:  12455690 H 22499
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.3737 MHz
Data Rate:  31.1016 Mbps
CN Failure: 7.2 dB

status Locked | signal -8.7 dBm | snr 13.8 dB | ber 0 | FE_HAS_LOCK


How does one know when to use u.data and when to use u.sdata?

I am presuming .sdata means signed. I just used u.data for status and it appears to be working OK.

Regards,

Richard

pendragon

Registered:
Posts: 1,017
Reply with quote  #64 
Yes, sdata means signed, which applies to signal level, and technically also to CNR.
midwestmac

Registered:
Posts: 2,275
Reply with quote  #65 
Quote:
Originally Posted by pendragon


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.


Thanks Pendragon for your advice. That helped
I noticed my signal level wasn't negative, I fixed that. Thanks
Code:

Tuned specs: 
System:     DVB-S 5 
Frequency:  12183 H 2785 
22khz:      ON 
Modulation: QPSK 0 
FEC:        3/4 7 
Inversion:  ON 1 
Rolloff:    35 0 
Pilot:      OFF 1 
MIS ID:        -1 
FRAME_LEN:  LONG 0 
Bandwidth:  3.7598 MHz 
Data Rate:  3.8499 Mbps 
CN Failure: 7.2 dB 
status Locked | signal -56.853 dBm |snr 12.901 dB |ber 0 |FE_HAS_LOCK 


Blindscan on  g28
Code:

$ blindscan-s2 -b -l 10600 -2 -s 11700 -e 12200 -H -t 10 
11758 H 3345  SIG -55.6 dBm SNR   7.2 dB DVB-S2 QPSK FEC_4_5  INV_ON  PIL_ON  ROL_20
11828 H 5000  SIG -54.5 dBm SNR   5.9 dB DVB-S2 8PSK FEC_3_4  INV_ON  PIL_ON  ROL_35
11862 H 27000 SIG -50.0 dBm SNR   9.4 dB DVB-S2 8PSK FEC_3_4  INV_ON  PIL_ON  ROL_35
11896 H 1716  SIG -54.6 dBm SNR  13.0 dB DVB-S2 32APSK FEC_3_4  INV_ON  PIL_ON  ROL_35
12131 H 11912 SIG -51.0 dBm SNR   8.4 dB DVB-S2 QPSK FEC_1_4  INV_ON  PIL_OFF ROL_35
12142 H 6337  SIG -52.2 dBm SNR  11.3 dB DVB-S  QPSK FEC_1_2  INV_ON  PIL_OFF ROL_35
12165 H 2785  SIG -54.3 dBm SNR   9.3 dB DVB-S2 8PSK FEC_5_6  INV_ON  PIL_OFF ROL_35
12172 H 2800  SIG -54.2 dBm SNR  10.7 dB DVB-S2 8PSK FEC_5_6  INV_ON  PIL_OFF ROL_25
12183 H 2785  SIG -53.7 dBm SNR  13.0 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12186 H 2785  SIG -53.6 dBm SNR  13.1 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12197 H 2785  SIG -55.5 dBm SNR   6.1 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35












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

Registered:
Posts: 58
Reply with quote  #66 
@ midwestmac

Hi,
Thanks for putting your blindscan-S2 app back up in your repo. Have just been having a play with it and it works fine although, like with my modified tune-s2, I'm seeing much higher strength levels than I'd expect.

Looking at yours above and given we're both running the same blindscan-s2 and driver, my output looks like this:
Code:

./blindscan-s2 -a 3 -b -l 10600 -2 -s 11700 -e 12750 -t 10 -c 4
12269 H 22500 SIG   6.0 dBm SNR  12.4 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12268 H 22500 SIG   6.1 dBm SNR  12.3 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12269 H 22500 SIG   5.9 dBm SNR  12.3 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12296 H 22500 SIG   6.3 dBm SNR  12.6 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12331 H 22500 SIG   5.7 dBm SNR  11.5 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12358 H 22500 SIG   6.2 dBm SNR  12.2 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12359 H 22500 SIG   6.3 dBm SNR  12.3 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12358 H 22500 SIG   6.2 dBm SNR  12.3 dB DVB-S2 8PSK FEC_2_3  INV_ON  PIL_ON  ROL_25
12421 H 22500 SIG   6.4 dBm SNR  11.2 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12456 H 22499 SIG   7.1 dBm SNR  12.3 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12456 H 22500 SIG   7.0 dBm SNR  12.3 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12457 H 22499 SIG   7.1 dBm SNR  12.4 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12457 H 22500 SIG   6.9 dBm SNR  12.3 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12484 H 22500 SIG   5.9 dBm SNR  11.4 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12483 H 22500 SIG   5.8 dBm SNR  11.4 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12519 H 22500 SIG   6.6 dBm SNR  12.4 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35
12546 H 22500 SIG   6.7 dBm SNR  12.3 dB DVB-S  QPSK FEC_3_4  INV_ON  PIL_OFF ROL_35


Nothing special in my setup - 60cm dish with Invercom LNB to 4x1 diseqc through about 8m of cable.

Next step to try to write a basic app to try to dump a spectrum scan to a file, for use with gnuplot.

Regards,

Richard
midwestmac

Registered:
Posts: 2,275
Reply with quote  #67 
Thanks for trying Richard wish it could of worked better for you.
I don't know why your signal level is reported like that. It doesn't seem right, like Pendragon said it should be a negative. I'll have to do a pull from bit bucket to make sure.
But you're saying your modified Tune-s2 gives the same signal levels??

Also, the repeats of the same signal I'm not sure but, it shouldn't be that bad. I'm using my 6 foot prime focus with an invacom lnbf.
 I went through several different DTV calls in the "get info" and that's where I left it at.
I thought DTV UPDATE STATUS would have fixed that but maybe DTV STATUS would be better.
Pendragon mentioned DTV_UPDATE_STATUS, DTV_UPDATE_FREQUENCY, DTV_UPDATE_CNR, and DTV_UPDATE_SIGNAL_LEVEL. So I guess we could play around with those.
and I never tried a sat with so many signals with  the same Sr's like you posted.

 P.S. Keep me posted on the spectrum scan `



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

Registered:
Posts: 58
Reply with quote  #68 
No, it works fine for me. I'm not too worried about the signal level at this point.

Bear in mind I've had to modify the saa716x driver in order to use pendragons driver, so perhaps something isn't quite correct with the setup there.

Using the exact same hardware lineup, but with the stock linux stv090x + stv611x drivers, the vdr PVR software I use shows strength around -35dBm, which seems reasonable. Using my modified tune-s2 and pendragon driver, it shows -8.7dBm.

If you're interested, have a look at at the attached screen grab at the bottom of this post:

http://rickcaylor.websitetoolbox.com/post/show_single_post?pid=1293765209&postcount=2489&forum=106995

which shows the same satellite scan, but using updateDVB and v4l-updatelee.

As for the multiple entries, these are quite strong transponders and pendragon gave us some tips to try to reduce this effect, earlier in the thread.

Regards,

Richard
pendragon

Registered:
Posts: 1,017
Reply with quote  #69 
When the driver receives a DTV_UPDATE_STATUS, DTV_UPDATE_FREQUENCY, DTV_UPDATE_CNR, and/or DTV_UPDATE_SIGNAL_LEVEL command, it interrogates the hardware to get the current parameter value. The non-UPDATE commands function according to the S2API - the driver returns what is in the parameter cache. This can be a stale value if sufficient time has passed since the driver last polled the hardware, such as the last DTV_TUNE. I added the DTV_UPDATE* commands so apps could periodically monitor changing parameters. This is helpful for tuning satellite dishes and tracking LNB frequency drift.

In terms of the signal levels, Richard has a STV6110 tuner on his card. The level calculation code I wrote in my stv0900 driver is tuner specific, and I was never able to test the STV6110 portion. However I took a quick look at this yesterday and didn't spot anything obvious that would add ~30 dB. The other possibility is the hardware implementation on the card. The derivation of the signal level in the demod requires knowledge of all of the gain blocks that precede it in the signal chain, including of course the tuner, the AGC loop, and anything else. This was straightforward for the Prof cards I mostly worked with when I wrote the driver, but another vendor could have implemented something quite differently. It's probably not that important, but it would be nice to figure this out.
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!