& moin
nox-: pong
moin crope, have you noticed reception issues with some rtl28xxu tuners recently?
someone it seems the driver is less sensitive now...
(with 0x1d19:0x1101 and nooelec 0x0bda:0x2838 at least, others still seem ok)
working: 4f4274af7009890f0d4724909bf9038193955489, broken: 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7
nooelec gets corrupted streams after channel switch, 0x1d19:0x1101 receives nothing anymore at all
s/someone/somehow/
there is no commit 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7
nox-: which tree has commit 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7 ?
git://github.com/torvalds/linux.git media_tree apparently
or is that the wrong one?
nox-: which is commit name and date?
hmm thats what hps wrote
guess ill ask him
I did a lot of changes recently to rtl2832u driver. some potential mistakes could be for example register caching, some volatile register is cached
i c...
this is supposed to be a 4.0rc tree
i seem to have https://github.com/torvalds/linux/blob/master/drivers/media/dvb-frontends/rtl2832.c
nox-: could you remove register caching and try if it helps
where is that?
dev->regmap_config.cache_type = REGCACHE_RBTREE,
change it to dev->regmap_config.cache_type = REGCACHE_NONE,
hmm nope, thats even worse
now even the rtl28xxu tuners that still worked are broken
how many tuners you have?
all rtl2832u devices were not broken, but only one?
yeah two were broken
i have 4 or 5 or so
<nox-> someone it seems the driver is less sensitive now...
<nox-> (with 0x1d19:0x1101 and nooelec 0x0bda:0x2838 at least, others still seem ok)
those numbers does not say anything
0x0ccd:0x00d3 now is broken too
which are RF tuner IC used?
oh
r820t was one broken one
https://wiki.freebsd.org/WebcamCompat - mine are in ther
e
what is tuners for those others?
http://rtlsdr.org/hardware-usb
E4000 now is broken too
(after your patch)
that one still worked before
FC2580 might be the other broken one
(somehow i thought it was FC0013, hmm)
0x1d19 0x1101 FC2580 Dexatek DK DVB-T Dongle (Logilink VG0002A)
mchehab: Hello, here's Felipe Sanches. I talked to you at some conference (probably at FISL) a few years ago.
mchehab: I was working on a userspace driver for a Zinwell ISDB-T 1-Seg USB receiver
mchehab: it was like 5 years ago, I guess.
hi FSanches
Recently I found the device in a box here in my house and got interested in working on it again
I improved the code a bit but still did not get it to work properly
I also started to port it to kernel-space
I'm commiting to a fork of your linux-media tree hosted at my github account here: https://github.com/felipesanches/linux-media/commits/zinwell
I do have access to the datasheet of the tuner (Maxim MAX2163) but I lack documentation on the other 2 chips:
MegaChips MA50159
and Somagic SMI-2020CBE
nox-: for me it seems to work, though I saw some I2C errors when used VLC... I think there could not be big issue as I havent got any bug reports...
so, it means my work is based on USB sniffer logs of the device while it was being controlled by the crappy proprietary windows program
well 4.0rc is still quite new so maybe you'll get the reports later
FSanches: ok. usb sniffing should work
especially for 1seg
mchehab: Lucas Villa Real is also working with me on this
crope, and i tested using vdr...
maybe you know him...
yes, I know him
:-)
don't hear about him for a while
So... it seems to me that the SMI-2020CBE chip is the one responsible for working as an i2c bridge over USB to allow the driver to communicate with the other 2 chips
it would be nice if you had the demod datasheet
nox-: I tested with VLC and dvbscan. And I have surely tested it using tzap, dvbv5-zap and dvbv5-scan when I did those changes as those are the tools I am using. usually I will get bug reports in a few days after patches are committed to media/master if there is big issues
as isdb-t has lots of parameters to set there
and it should be a little hard to get
yet, thankfully, most demods work in "auto" mode
crope, lets me test using vlc too
crope, getting corrupted streams with r820t
with vlc
getting everything they need from the TMCC carrier
nox-: is your signal very weak?
it is kinda weak but worked with eaerlier driver versions
let me ask you something simple... Is this i2c bridging over usb functionality the thing that characterizes a "dvb_frontend" in the code ?
crope, as i said it looks like the driver has become less sensitive
still waiting for picture with e4000...
..on vlc
As far as I can tell (by searching the current media codebase) this chip (Somagic SMI2020CBE) is still not supported by Linux so I'll have to add some code for that. Should I start fresh or should I append it to an existing source module? I mean... it is hard to classify this one grouped to other already supported devices. For instance, is there any ISDB-T device already supported?
nox-: e4000 works too. what it reports as a NNR?
CNR
Lock (0x1f) Signal= 93.73% C/N= 27.25dB postBER= 0
where do i see that with vlc?
vlc does not show any signal statistics
use dvbv5-zap
ah ok
ill ise vdr-pluging-femon
use
no str reading, snd 00f3
snr
(0%)
Lock (0x1f) Signal= 92.94% C/N= 32.67dB postBER= 0
first CNR was e4000 and second one r820t
mind you with e4000 this is only broken with your oneliner patch
let me remove that and test again
now vdr works again but snr is still as low
..and vlc gets no picture, only vdr does
vlc is weird, i dont even see how i switch channels...
(i get picture with r820t w/o your oneliner patch)
you have to make playlist first which contains all the channels. after that could could pick channel from playlist
hm ok i just entered mux freq...
but anyway, vlc is broken with e4000 here
mchehab: I just got my first good isochronous responses from the Zinwell ISDB-T device :-)
I'll finish porting this userspace script to kernelspace and hopefully I'll get this thing working on Linux! I'm very excited about it! Woo-hoo!!!
crope, and your oneliner patch only makes reception worse here
crope, so i suppose there are still bugs
bbl
ola
hola
q tal
FSanches: sorry, was busy with other things...
a dvb_frontend is actually a tuner + demod
(and SEC, for DVB-S/S2)
except for max2163, you should write a new set of drivers, as those chips are different than the ones we use
I think we have already a driver for max216x
if so, the best is to try to reuse it