<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
dongs: oh heh
<br> they got rid of tuning caps
<br> lowered vcore
<br> and only lowif output
<br> <u>xdarklight</u>: AGCRD[15:0] is at 86,87 in 1st bank
<br> 7B should be set to 0 for agc filter value / input signal level to be read from AGCRC
<br> lock stuff is also prety clear. poke me back wehn you're alive and i'll pass on info
<br> DVB-T lock: read SSEQRD_T from DVB-T bank, & 0x0F. Value > 10 = lock
<br> DVB-T2 lock: read SSEQFLG from T2 bank, & 0x0F, Value > 13 = lock
<br> DVB-C lock: read SSEQMON2_C from DVB_C bank, & 0x0F, Value > 8 = lock
<br> SSEQRD_T = addr 0x62
<br> SSEQFLG = 0x82
<br> SSEQMON2_C = 0x84
xdarklight: <u>dongs</u>: does the datasheet say something about the value range of AGCRD?
dongs: what do you wanna know about it?
<br> http://bcas.tv/paste/results/B5J6rW77.html
<br> this is how the driver returns it
<br> even tho its shown in datasheet as agcrd[15:0]
<br> AGCRC[15:6] is valid and it is 10bit binary.(????) Small values indicate low signal levels, whie large values indicate high signal levels.
<br> and nope
<br> says nothing about its range
xdarklight: <u>dongs</u>: ah, there's some calculation :)
dongs: its weird.
<br> wtf is 10bit binary?
<br> 10-bit binary codes[edit]
<br> AUTOSPEC – Also known as Bauer code. AUTOSPEC repeats a five-bit character twice, but if the character has odd parity, the repetition is inverted
<br> this?!
<br> anyway just do that high << 2 | low >> 6 I guess and call it a day
<br> sinec that what the driver does.
xdarklight: yep, I just have to scale it to 16bit, because that's what the linux kernel expects
dongs: pana driver makes it uint32 but it probably wont even reach full 16bits range anyway
<br> what values range have you seen for the high byte?
<br> anything > x80?
xdarklight: <u>dongs</u>: a few minutes ago I got 0x89 (in reg 0x86)
dongs: well, poop
<br> what does the result lok like after <<2 >>?
<br> 6
<br> look
<br> maybe you can shift it all >> 2 safely
xdarklight: hang on, checking
<br> <u>dongs</u>: 0x021b to 0x0224 - rtl2832 reports 93% signal strength at the same time
<br> now got some 0x0218 as lower bound, but you pretty much get the range
dongs: how can it be so low if you said 86 was > 0x80
<br> in that paste ret = uint32 type
<br> so ret = upper << 2 | lower >> 6;
xdarklight: for one 0x0218 result: upper = 0x86, lower = 0x00
dongs: oh.
<br> oh yeah ,shit never mind it'll nver be > 16bit even if its FF because its only shifting it up by 2 not shiftingi t up by 2 from bits 15..8
<br> so you dont need to scale anythign
xdarklight: (before reading 0x86 / 0x87 I'm writing 0x00 to 0x7b once - or do I have to do this before reading 0x86 and again before reading 0x87?)
dongs: no, don't do that
Patrick__: Hi, I try to using WinTV dualHD DVB-C stick in raspbian. I know it's currently in deveopment but how to get it to work with the first tuner (see https://patchwork.linuxtv.org/patch/33811/)?
dongs: just see that 7B has zero in it
<br> at start or something
<br> thats what makes agcrc output the agc loop value
<br> zero is default, so unless something else touches it, you dont need to write it
<br> you do need to read upper, lower in sequence, are you doing it as 2 byte read?
<br> oh wait, the sample code does it single byte anyway
<br> so it probly doesnt matter
xdarklight: yep, doing two single byte reads
dongs: should be good to go then
<br> CNR formula is pretty nasty
<br> http://bcas.tv/paste/results/EQLRjk44.html does use log10 tho
<br> but givs you what looks like xx.yy as 2 decimals
<br> CNRDU_T = 8F/90
xdarklight: there's some log10 code in the linux DVB kernel code
dongs: CNRDU = B8/B9
<br> CNFLG = B7
<br> CNMON1_C = A1/A2/A3/A4
<br> in appropriate banks (T, T2, C)
xdarklight: <u>dongs</u>: I switched from DVB-T to DVB-C (means I cannot use rtl2832 for reading signal strength anymore, but I used another device with DVB-C support that reads signal strength), now I get upper = 0xbf, lower = 0x80
<br> on the other device this reads as ~99% signal strength
dongs: yeah agc calc is same in all modulations
<br> i guess you dont have attenuator to actually affect the signal and measure it?
xdarklight: no (it's the first time I'm playing around with this kind of stuff ;))
dongs: so that ends up being 0x2fe for strength
xdarklight: yep, now the linux DVB framework expects a 16 bit value representing the "percentage" (so 0xffff = 100% strength, 0x0000 = 0% strength)
<br> if I scale the values up linear I only get 53% for DVB-T and 74% for DVB-C
dongs: printf("AGC : %4d ",param->info[DMD_E_INFO_AGC] );
<br> the driver is not very helpful :)
xdarklight: <u>dongs</u>: is this the calculation for CNR in dB or some different unit?
<br> (based on the values I get: seems that it is)
dongs: <u>xdarklight</u>: dB yes
<br> <u>xdarklight</u>: its presented as dec.div... so y ou show it like %02d.%02d dB, cnr_i, cnr_d
<br> and ex. get 20.5dB or whatever
<br> er 20.50
xdarklight: <u>dongs</u>: mn88473 gives me 22,56dB, rtl2832 28,23dB
<br> not sure why that is though (value is taken from DVB-T), because DVB-C looks good
<br> (on DVB-C my other device and mn88473 report ~32dB)
dongs: mhm
<br> 22 is pretty shitty yeah
<br> taking nubmers from rihgt bank, yeah?
xdarklight: yep, bank is correct
<br> <u>dongs</u>: https://paste.kde.org/pohoea2gp if you are interested in the code
<br> I don't fully understand the intlog10 function though
<br> updated version which also include the DVB-T2 (can't test this one though) and DVB-C code: https://paste.kde.org/pkvql2ztv
dongs: god what an awful paste site
<br> checking
<br> uitmp = 65536 / (tmp_upper << 8) | tmp_lower;
<br> i dont like this
<br> i'd add extra ()'s there
<br> 65536 / ((tmp_upper << 8) | tmp_lower) just to make sure
<br> lemme see what log10_easy outputs in
<br> http://bcas.tv/paste/results/Wy1EXp55.html looks like uses a lookup table
xdarklight: <u>dongs</u>: hah!
<br> <u>dongs</u>: looks like I f*cked up the braces
<br> ah no
<br> wrong frontend :/
<br> <u>dongs</u>: ah, I think I see it - intlog10 chops the value to 8bit
<br> <u>dongs</u>: I fixed the maths stuff, but the result is the same: CNR on DVB-C is fine, but on DVB-T it's below 23dB
<br> (rtl2832 currently reports a CNR of 29dB)
<br> but I have to admit that my DVB-T antenna is ultra cheap and my reception is indeed not very good
<br> so I'm assuming that rtl2832 has a bit too optimistic values
dongs: hm
<br> possibly, could also be shitty tuner/etc hardware
<br> wihtout attenuator or a signal gen hard to tell
<br> i guess windows apps these days dont show CN value etc.
<br> just BDA strength/shit in %
xdarklight: <u>dongs</u>: I'm wondering if signal strength is something like this: https://en.wikipedia.org/wiki/Densely_packed_decimal
<br> but the reference implementation doesn't do anything similar
dongs: i suppose "10bit decimal" can be a translation fail of BCD heh...
xdarklight: I tried to do some BCD calculations but the results don't make sense
<br> I'm calling it a day for now
<br> thanks for now dongs :)
dongs: yep
yang: I am not sure why this scan is giving me garbage data http://paste.debian.net/715301/