[SOLVED] Signal measurements with the TBS8922

[jsveiga]

Hello,

We were using the TBS8921 for getting signal measurements for an automatic dish pointer, but had to upgrade to the TBS8922.

With the TBS8922, measurements do not seem right.

Environment:
Linux debian squeeze, kernel 2.6.32-5-686 32 bits
TBS drivers v 121119

Below are measurements taken with the szap-s2 provided with the TBS drivers, without anything connected to the RF input.

With the 8922, the signal level jumps all around, snr is very good (although there is no signal nor lock), and there are ber values.

root@sat2000a:/home/jsveiga/src/szap-s2# dmesg | egrep -i "dvb|cx88"
[ 3.219209] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 3.220561] cx88[0]: subsystem: 8922:8888, board: TBS 8922 DVB-S/S2 [card=90,autodetected], frontend(s): 1
[ 3.220567] cx88[0]: TV tuner type 4, Radio tuner type -1
[ 3.235695] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 3.734566] input: cx88 IR (TBS 8922 DVB-S/S2) as /devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0/input6
[ 3.734646] rc0: cx88 IR (TBS 8922 DVB-S/S2) as /devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0
[ 3.734816] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input7
[ 3.734961] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[ 3.734967] cx88[0]/2: cx2388x 8802 Driver Manager
[ 3.734992] cx88-mpeg driver manager 0000:03:00.2: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 3.735004] cx88[0]/2: found at 0000:03:00.2, rev: 5, irq: 20, latency: 32, mmio: 0x80000000
[ 3.735013] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[ 3.735251] cx8800 0000:03:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 3.735263] cx88[0]/0: found at 0000:03:00.0, rev: 5, irq: 20, latency: 32, mmio: 0x81000000
[ 3.735278] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[ 3.735418] cx88[0]/0: registered device video0 [v4l2]
[ 3.735469] cx88[0]/0: registered device vbi0
[ 3.780116] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 3.780123] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 3.780130] cx88[0]/2: subsystem: 8922:8888, board: TBS 8922 DVB-S/S2 [card=90]
[ 3.780135] cx88[0]/2: cx2388x based DVB/ATSC card
[ 3.780139] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 4.112719] DVB: registering new adapter (cx88[0])
[ 4.112726] DVB: registering adapter 0 frontend 0 (TurboSight TBS 8922 DVBS/S2 frontend)...
root@sat2000a:/home/jsveiga/src/szap-s2# ./szap-s2 -O 35 -S 0 -C 34 -M 2 -c sat.conf -l STANDARD "CH1"
reading channels from file 'sat.conf'
zapping to 1 'CH1':
delivery DVB-S, modulation QPSK
sat 0, frequency 11135 MHz H, symbolrate 28880000, coderate 3/4, rolloff 0.35
vpid 0x1fff, apid 0x1fff, sid 0x0001
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 00 | signal 6635 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4a84 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4ea4 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 43c3 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 57a5 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4c24 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4153 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 5144 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 5ac5 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 6a06 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4eb4 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 42b3 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 5765 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4aa4 | snr 014a | ber 03ffffff | unc 00000000 |

for comparison, here's the output for the TBS8921, swapped with the TBS8922 on the same system:

root@sat2000a:/home/jsveiga/src/szap-s2# dmesg | egrep -i "dvb|cx88"
[ 3.197380] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 3.198762] cx88[0]: subsystem: 8921:8888, board: TBS 8921 DVB-S/S2 [card=89,autodetected], frontend(s): 1
[ 3.198768] cx88[0]: TV tuner type 4, Radio tuner type -1
[ 3.210250] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 3.712631] input: cx88 IR (TBS 8921 DVB-S/S2) as /devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0/input6
[ 3.712712] rc0: cx88 IR (TBS 8921 DVB-S/S2) as /devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0
[ 3.712885] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input7
[ 3.713029] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[ 3.713035] cx88[0]/2: cx2388x 8802 Driver Manager
[ 3.713060] cx88-mpeg driver manager 0000:03:00.2: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 3.713072] cx88[0]/2: found at 0000:03:00.2, rev: 5, irq: 20, latency: 32, mmio: 0x80000000
[ 3.713082] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[ 3.713385] cx8800 0000:03:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 3.713399] cx88[0]/0: found at 0000:03:00.0, rev: 5, irq: 20, latency: 32, mmio: 0x81000000
[ 3.713416] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[ 3.713570] cx88[0]/0: registered device video0 [v4l2]
[ 3.713626] cx88[0]/0: registered device vbi0
[ 3.753467] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 3.753474] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 3.753481] cx88[0]/2: subsystem: 8921:8888, board: TBS 8921 DVB-S/S2 [card=89]
[ 3.753486] cx88[0]/2: cx2388x based DVB/ATSC card
[ 3.753490] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 3.788174] DVB: registering new adapter (cx88[0])
[ 3.788182] DVB: registering adapter 0 frontend 0 (TurboSight TBS 8921 DVBS/S2 frontend)...
root@sat2000a:/home/jsveiga/src/szap-s2# ./szap-s2 -O 35 -S 0 -C 34 -M 2 -c sat.conf -l STANDARD "CH1"
reading channels from file 'sat.conf'
zapping to 1 'CH1':
delivery DVB-S, modulation QPSK
sat 0, frequency 11135 MHz H, symbolrate 28880000, coderate 3/4, rolloff 0.35
vpid 0x1fff, apid 0x1fff, sid 0x0001
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 01 | signal fcfe | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfa | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfb | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfc | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfc | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfc | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd00 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfd | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd01 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fcfc | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd01 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd01 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd01 | snr 0000 | ber 00000000 | unc 00000000 |

How do I get correct level and snr measurements with the TBS8922 ? (I do not use ber, but I do need level and snr).

edit: Note: I have "options tbsfe esno=1" on my /etc/modprobe.d/tbsfe.conf

Thanks!

Joao S Veiga

[cody]

hello, what you get is the normal behaviour, i.e. 8922 outputs "snr 014a | ber 03ffffff" when there is no signal lock, i.e. it outputs the maximum BER and the maximum SNR (of 33 dB or 0x14a) to indicate there is no signal lock, because basically those maximum values are unreachable in practice.

[jsveiga]

Thank you!

I'll modify my program to ignore those values.

And what about the signal readings? Was there a change in the scale from 8921 to 8922?

I also noticed that status for the 8921 was 01, whereas it was 00 for the 8922. Is that correct?

Thanks again,

Joao S Veiga

[updatelee]

Do they use different drivers? If so prob can't be compared

[jsveiga]

Sorry, but if they show readings in dBm (or dB for snr), they should be comparable. Of course small differences could occur, as the board is not a precision measurement instrument.

If you have say, -30dBm of signal with 15dB of snr at the RF connector, these measurements *are* comparable between different boards and drivers.

For the "percent" reading, what may have changed is the scale of the values reported by the hardware/driver, and that was my last question (because the reported values I see are way too different). For example, one could have a 100% range represented by 0x0000-0xffff and the other 0xff00 - 0xff64?

The 8922 signal measurement also fluctuates much more than the ones from the 8921, which, if that's it, means I'm doomed, as I use the signal level to automatically peak the antenna targeting.

regards,

Joao S Veiga

[updatelee]

maybe they *should* be but they arent. Straight up, just arent. I have a Prof 7500 (stv0900 w/stb6100) and a TBS6925 (stv090s w/stb6100), they use two different drivers (stv0900 and stv090x) and the signal levels are NOT comparable. even between my Prof 7500 and 7301 (exact same chipset, just different drivers) they are not comparable. To be comparable someone has to have access to a lab grade spectrum analyzer and various attenuators. I have both (not calibrated though, but close enough) but havent had time to actually write down a proper lookup table, cause frankly its just not that big of a deal to me, the linux drivers have imo more important things I want worked on. The plus of open source is we have the ability to fix things ourselves, the downside is we have to fix things ourselves.

Windows is no better btw, nor are set top box's. Its just not a priority.

[jsveiga]

the tbs front end drivers are not 100% open source. You compile the v4l drivers and they link to tbs binaries. Tbs was very helpful before with a lock reacquire problem I found on the 8921, so I'm back for their excellent support.
I'm ok with changing my prog to accomodate for differences, but if someone provides useful information like tbs did in this same thread, it saves me hacking time.
I had the solution devloped for the 8921, but purchasing could not get those for this batch.
Getting back and forth to this thread to read and reply to non-answers is also a waste of time, so goodbye; I'll be back if someone posts something useful.
(posting from a phone, so please excuse me for the formatting)

[updatelee]

The closed src binary doesnt have anything todo with signal levels. At least in the stv090x/stv0900 drivers it doesnt. On the 6925 it just controls the voltage switching and enables the saa716x sending packets.

[jsveiga]

Hi Constantine,

I got a sunny day, so was able to pull the dish pointer trailer out for some tests...

It seems there was really a scale change between the 8922 and 8921, something around 100x, so that's why I was seeing the 8922 values "jump all over": It's just that the 8921 values fluctuations are about 100x smaller due to the scale.

Getting szap-s2 measurements with/without signal from the 8921 and 8922 resulted in the values at the end of this post (module loaded with option to show signal in % and snr in dB):

The 8921 signal/no signal values changed about 360 (decimal) units, whereas 8922 values changed about 32800 (decimal) units, so about 100x. On the 8921, I'd use (value - 0xfe20) to get something around the 0-100 range. For the 8922, it seems it's as in the szap-s2 -H: (value/0xffff * 100). I don't need accuracy on the signal percentage, just a roughly 0-100 range to auto-peak the pointing.

As for the snr, we only see a variation of about 2dB between the 8922 and 8921 which is quite COMPARABLE and ok for our purposes.

Thanks again for the support!

Best regards,

Joao S Veiga

8921 signal

status 1f | signal fe73 | snr 007a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe71 | snr 007a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe71 | snr 007b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe71 | snr 007b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe71 | snr 007a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe71 | snr 007b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe72 | snr 007b | ber 00000000 | unc 00000000 | FE_HAS_LOCK

8921 no signal

status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd03 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd08 | snr 0000 | ber 00000000 | unc 00000000 |
status 01 | signal fd03 | snr 0000 | ber 00000000 | unc 00000000 |


8922 signal

status 1f | signal d53c | snr 0065 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d51c | snr 0065 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d51c | snr 0065 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d50c | snr 0064 | ber 0000000e | unc 00000000 | FE_HAS_LOCK
status 1f | signal d51c | snr 0064 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d4dc | snr 0064 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d4fc | snr 0064 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal d4fc | snr 0064 | ber 00000000 | unc 00000000 | FE_HAS_LOCK


8922 nosignal

status 00 | signal 7b77 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4033 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 54d4 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 5945 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4de4 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 4223 | snr 014a | ber 03ffffff | unc 00000000 |
status 00 | signal 5795 | snr 014a | ber 03ffffff | unc 00000000 |