xdarklight: yes
15:34 < dongs> status update on pana demod: 'demod product line is transferred to new company, i'm trying to get new support window
15:34 < dongs> https://en.wikipedia.org/wiki/Socionext
15:34 < dongs> thats waht they got renamed to
hello paranoids and trolls
dongs: ok so in other words "will take a while until you get an official answer about the signal strength value range"
merbzt: merbanan: maybe you can answer my question from yesterday (mn88473): I am right that the PER values go to block_error=(error * 100) and block_count=per_len, and the BER values go to post_bit_error=error post_bit_count=sum (or would this go into pre_bit_* instead?)
so true: "Remember this year's year of the Linux desktop is brought to you by Windows 10."
SupDudes: heh :)
xdarklight: what are you calculating ?
merbzt: I'm calculating the values as specified in your wiki page
is your question related to my signal strength statement or my PER/BER question?
Pretty sure the guy on the stand now is dongs
talking about lunix dvb
xdarklight: correct
<n00b750> holy fk. all this stuff is a mess. why are there so many changes all the time to these drivers. too many cooks in the kitchen?
xdarklight: you have to elaborate you question if you didn't get an answer already, I don't understand exactly what you are trying to calculate
n00b750 would have been happy today
someone here was using turbo8psk something genpix tuner
and digicipher2 has been hax0red
merbzt: ok, let me rephrase it: I've calculated BER and PER as defined in the wiki. my question is now how these values map to the linux DVB API
my assumption is that the values "PER" values go into struct dtv_frontend_properties' block_error and block_count
and the "BER" values go into struct dtv_frontend_properties' post_bit_error and post_bit_count
you actually have hopes that Lunix has a standard format to report information back from the driver to the DVB API?
SupDudes: well, at least two other drivers (drxk and rtl2832) are reporting back this info - so I'm hoping that it's reusable ;)
xdarklight: the dvb v5 api has another way to report such values
merbzt: huh? I though struct dtv_frontend_properties is v5 API
(I though that dvb_frontend_ops.read_ber, .read_ucblocks etc. are old API)
yes that is correct
Welcome to Lunix TV/DVB, where APIs/specs change every year
merbzt: so am I using the correct way (then the question is just: am I using the right fields) or what is the correct way otherwise?
ahh, that I don't know
mauro or crope should know better then me
but just map it to something
if it is wrong it will turn up on the patch review
https://git.linuxtv.org/media_tree.git/tree/drivers/media/dvb-frontends/af9033.c
 af9033_stat_work
You can also ask dongs, he's a Lunix TV kernel expert
he usually has all the answers regarding this
merbzt: yep, those are the fields I'm using
so let's wait for one of the other guys then :)
xdarklight: all the stats stuff are kinda custom, it is hard to normalize quality fields
the nordig dvb specs actually has a signal quality formula that is implemented on complaint dvb boxes
unfortunately the dvb api doesn't have this afaik
so right now you can only reliably compare different units
signal stats should be fine though, modulation etc
CNR for example works fine
but like you said: unit is always fixed to dB
APIs/specs change every year
every year?? haha
more like every fucking week