Opened 14 years ago

Closed 14 years ago

#616 closed defect (fixed)

Wrong SNR/SIG values for some DVB cards

Reported by: Adam Egger Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords: dvb
Cc: Ticket locked: no

Description

The signal monitor shows wrong values for several DVB card types. My Airstar2 (b2c2_flexcop_pci) shows 49% for all channels, which makes the antenna adjustment mode and the values the signal monitor shows in LiveTV quite unusable for several users. Btw, the value shown in Kaffeine is always correct.

Daniel's comment on this:


 65535*0.23 - 32768 => -17695[[BR]]
 65535*0.49 - 32768 => -655.85

-17695 +/- 700, and -655.85 +/- 700 are the values I'd expect the driver is giving for signal.

So I found your logging on the mailing list...

2005-10-23 15:26:22.911 SIGNAL: SNR (0)
2005-10-23 15:26:22.966 SIGNAL: SIG (-157)
2005-10-23 15:26:22.967 SIGNAL: SNR (0)
2005-10-23 15:26:23.022 SIGNAL: SIG (-203)
2005-10-23 15:26:23.023 SIGNAL: SNR (-31355)
2005-10-23 15:26:23.085 SIGNAL: SIG (-197)
2005-10-23 15:26:23.085 SIGNAL: SNR (-23131)

Ok, the problem here is that MythTV tries to detect when the signal value is bogus, and use the SNR, in your case the driver is reporting a signal value that doesn't appear bogus to MythTV. Look in tv_play.cpp at TV::UpdateOSDSignal(). You will see that a bogus signal value is considered to be anything in the vicinity of 0% or 100%, in your case a value of 23% or 49% could be a perfectly valid value.

There are three routes to fixing this: make MythTV better at detecting broken drivers, fix the DVB drivers for the card you are using to report a valid signal value (even if it is just a re-branded SNR), or add yet another configuration setting to MythTV. I'd prefer one or both of the first two solutions.

Change History (6)

comment:1 Changed 14 years ago by danielk

Milestone: 0.20
Owner: changed from Isaac Richards to danielk

We could detect the frontend name and always display the SNR for it. Have you asked the DVB mailing list about this?

comment:2 Changed 14 years ago by john.pullan@…

I remember looking at the Kaffeine code for the signal values. It looks like they just use the raw values rather than using any post processing on them.

comment:3 Changed 14 years ago by danielk

Resolution: invalid
Status: newclosed

I'm marking this as invalid. This is really a feature request, since MythTV does show the correct Signal value, it just doesn't ignore the signal value when the driver is broken in a strange ways.

Reopen w/patch.

comment:4 Changed 14 years ago by Adam Egger

The b2c2_flexcop_pci aka skystar2 provides now quite correct values with kernel 2.6.14 instead of 49% for all channels until 2.6.13. It unfortunately uses uint32_t instead of int16_t, what means: 0 = 0% and FFFF = 100%.

I found Taylor's answer to this in -dev: http://mythtv.org/pipermail/mythtv-dev/2005-June/036980.html So we just have to hope they all will use int16_t as SIG and SNR for all DVB drivers.

"Each DVB driver does it differently. There are no units because on many demods that have been reverse engineered no one knows what the units really are.

Here is one example. The value can be 0-0xFFFF. I did some checking and found that 32DB is very very high for ATSC reception and so I made the SNR value for the Nxt2002 go from 0 (0db) - 0xFFFF (32db).

The Hd2k/3k cards report the value as just the actual unit so 32db would be 0x0020.

Great system right? There really isn't much of a way to fix this other than hope the drivers return some reasonable value.."

comment:5 Changed 14 years ago by danielk

Milestone: 0.200.19
Resolution: invalid
Status: closedreopened

So in the next API, DVB API 4.0 the signal_strength and snr are uint16_t rather than int16_t. For the forseeable future only unsigned 15 bit integers make any sense in either of these fields for backwards compatiblity for applications. So..

Since the 3.x API is either not respected at all or the driver writers usually had enough sense to only use values in the safe range of 0..7fff, we should move on to supporting the 4.0 API here and put some comments in the code so it doesn't get 'fixed' again later. The downside is that cards with correct signal reporting will only use the lower half of the signal bar, but this should magically correct itself as drivers get moved to the 4.0 API.

comment:6 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(In [8038]) Fixes #616.

This should make DVB drivers that report the signal improperly work better, and still be compatible with well implemented drivers.

The problem is really in the DVB API v 3.x being unclear for both the signal and signal-to-noise ratio. This isn't properly addressed in the 4.0 API, but the API has been changed to better reflect practice so I'm using it for interpreting these values. The proposed 4.0 API still does not specify how the drivers should calculate these values; but any one looking at both the 3.1 and 4.0 API's should see that these values should be in the range 0..32767 so that they will always change monotonically with respect to signal quality changes for anyone implementing either API.

Note: See TracTickets for help on using tickets.