Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DTTV measurements
60 views
Skip to first unread message
Jim Lesurf
Oct 18, 2012, 12:43:45 PM10/18/12
to
Those who follow the digital-tv newsgroup will have seen the postings wrt
measurements of DTTV kit. I had hoped to use the 290e PC tuner to give
useful measurements of mux signal levels, but I seem to have hit a problem
with the 290e. I'm not sure if the problem is with the meter or with the
'tzap' software...
I can use a calibrated signal level meter (Fringe electronics) to measure
the total DTTV mux powers summed across the UHF band. But that doesn't tell
me about any individual mux levels, just the total.
I'd *assumed* the 'signal' values returned by tzap would indicate the power
level of the tuned mux. So I did some runs, recording the tzap reports
whilst adjusting the input level with a variable UHF attenuator.
The reported signal levels essentially don't change as I wind up and down
the input signal levels.
My guess at present for the reason is that the 290e included an RF-stage
AGC that scales the levels passed into the rest of the tuner to ensure that
the total is 'about right to process'. So as I wind the input RF levels of
all the muxes up or down, this AGC corrects the changes. The sensed 'signal
level' then comes out much the same as one process corrects for the other.
An alternative possibility is that something isn't right about the tzap
software for how it works out the signal level values.
But at present I can see the behaviour, but am not sure of the cause.
As it is I can wind up and down signal levels over 20dB or more, and all
that happens is that when a given mux gets too low in level the ber errors
start to appear. But the reported signal level is much the same as when the
mux is far more powerful.
One feature is that some muxes are always "100%" (0xffff) but other have
lower values like 80%, and this pattern also persists as all the muxes are
wound up or down in power. This is what makes me think the problem is
either an overall AGC or the software doing something similar.
Anyone done any similar measurements or can shed any light on this?
Slainte,
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
measurements of DTTV kit. I had hoped to use the 290e PC tuner to give
useful measurements of mux signal levels, but I seem to have hit a problem
with the 290e. I'm not sure if the problem is with the meter or with the
'tzap' software...
I can use a calibrated signal level meter (Fringe electronics) to measure
the total DTTV mux powers summed across the UHF band. But that doesn't tell
me about any individual mux levels, just the total.
I'd *assumed* the 'signal' values returned by tzap would indicate the power
level of the tuned mux. So I did some runs, recording the tzap reports
whilst adjusting the input level with a variable UHF attenuator.
The reported signal levels essentially don't change as I wind up and down
the input signal levels.
My guess at present for the reason is that the 290e included an RF-stage
AGC that scales the levels passed into the rest of the tuner to ensure that
the total is 'about right to process'. So as I wind the input RF levels of
all the muxes up or down, this AGC corrects the changes. The sensed 'signal
level' then comes out much the same as one process corrects for the other.
An alternative possibility is that something isn't right about the tzap
software for how it works out the signal level values.
But at present I can see the behaviour, but am not sure of the cause.
As it is I can wind up and down signal levels over 20dB or more, and all
that happens is that when a given mux gets too low in level the ber errors
start to appear. But the reported signal level is much the same as when the
mux is far more powerful.
One feature is that some muxes are always "100%" (0xffff) but other have
lower values like 80%, and this pattern also persists as all the muxes are
wound up or down in power. This is what makes me think the problem is
either an overall AGC or the software doing something similar.
Anyone done any similar measurements or can shed any light on this?
Slainte,
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Andy Furniss
Oct 18, 2012, 3:30:12 PM10/18/12
to
Maybe you could subscribe and ask on linux-media where the devs lurk -
http://vger.kernel.org/vger-lists.html#linux-media
From seeing this in dmesg
tda18271: performing RF tracking filter calibration
tda18271: RF tracking filter calibration complete
it looks like the 290e uses this as a tuner -
www.nxp.com/documents/data_sheet/TDA18271HD.pdf
and modinfo shows you can turn up debugging level -
root@noki:/home/andy# modinfo tda18271
filename:
/lib/modules/3.5.3/kernel/drivers/media/common/tuners/tda18271.ko
version: 0.4
license: GPL
author: Michael Krufky <mkr...@linuxtv.org>
description: NXP TDA18271HD analog / digital tuner driver
srcversion: 9D1491670F3B32E558D111C
depends:
intree: Y
vermagic: 3.5.3 SMP preempt mod_unload PENTIUMIII
parm: debug:set debug level (info=1, map=2, reg=4, adv=8,
cal=16 (or-able)) (int)
parm: cal:perform RF tracking filter calibration on startup (int)
PS Did you see my reply to "What the FEC?" I was using a different
server and am not sure how well it propagated (though it made it to Google).
Johann Klammer
Oct 19, 2012, 2:50:24 AM10/19/12
to
different modules implement it in arbitrary ways. You'll have to grind
through the relevant kernel sources and the (complete) datasheets (_if_
you can get those).
Jim Lesurf
Oct 19, 2012, 4:23:56 AM10/19/12
to
In article <5080f830$0$1566$91ce...@newsreader04.highway.telekom.at>,
it was tzap so that I might be able to write a tweaked version. :-) Alas,
kernel modules are - so far - well beyond what I've managed to understand
beyond the general level.
Johann Klammer <klam...@NOSPAM.a1.net> wrote:
> Jim Lesurf wrote:
> > Those who follow the digital-tv newsgroup will have seen the postings
> > wrt measurements of DTTV kit. I had hoped to use the 290e PC tuner to
> > give useful measurements of mux signal levels, but I seem to have hit
> > a problem with the 290e. I'm not sure if the problem is with the meter
> > or with the 'tzap' software...
> >
> > I can use a calibrated signal level meter (Fringe electronics) to
> > measure the total DTTV mux powers summed across the UHF band. But that
> > doesn't tell me about any individual mux levels, just the total.
> Jim Lesurf wrote:
> > Those who follow the digital-tv newsgroup will have seen the postings
> > wrt measurements of DTTV kit. I had hoped to use the 290e PC tuner to
> > give useful measurements of mux signal levels, but I seem to have hit
> > a problem with the 290e. I'm not sure if the problem is with the meter
> > or with the 'tzap' software...
> >
> > I can use a calibrated signal level meter (Fringe electronics) to
> > measure the total DTTV mux powers summed across the UHF band. But that
> > doesn't tell me about any individual mux levels, just the total.
> The linux kernel interface to those stats is rather sloppy, and the DVB
> different modules implement it in arbitrary ways. You'll have to grind
> through the relevant kernel sources and the (complete) datasheets (_if_
> you can get those).
Is the problem likely to be in the kernel modules, or in tzap? I was hoping
> different modules implement it in arbitrary ways. You'll have to grind
> through the relevant kernel sources and the (complete) datasheets (_if_
> you can get those).
it was tzap so that I might be able to write a tweaked version. :-) Alas,
kernel modules are - so far - well beyond what I've managed to understand
beyond the general level.
Jim Lesurf
Oct 19, 2012, 4:31:09 AM10/19/12
to
In article <k5ple7$ham$1...@localhost.localdomain>, Andy Furniss
<sp...@andyfurniss.entadsl.com> wrote:
any clues. My confidence in getting fixes from dev lists is low because I
never got much from that for ALSA and had to experiment and DIY/hack my own
way to solutions to problems! But the above group may be much more
responsive.
I was sort-of hoping the bottleneck was in something like tzap that I could
get the source for and tweak. Never done anything at the kernel module
level beyond a bit of basic param changing, etc.
> From seeing this in dmesg
> tda18271: performing RF tracking filter calibration tda18271: RF
> tracking filter calibration complete
> it looks like the 290e uses this as a tuner -
> www.nxp.com/documents/data_sheet/TDA18271HD.pdf
Thanks for that.
> and modinfo shows you can turn up debugging level -
> root@noki:/home/andy# modinfo tda18271 filename:
> /lib/modules/3.5.3/kernel/drivers/media/common/tuners/tda18271.ko
> version: 0.4 license: GPL author: Michael Krufky
> <mkr...@linuxtv.org> description: NXP TDA18271HD analog / digital
> tuner driver srcversion: 9D1491670F3B32E558D111C depends: intree:
> Y vermagic: 3.5.3 SMP preempt mod_unload PENTIUMIII parm:
> debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
> (or-able)) (int) parm: cal:perform RF tracking filter
> calibration on startup (int)
Afraid at present I don't know how to use that to investigate or make any
changes. I'll do some searching to see if I can find an explanation I can
follow.
> PS Did you see my reply to "What the FEC?" I was using a different
> server and am not sure how well it propagated (though it made it to
> Google).
I think I did. But I can't now recall as I've forgotten the details. Was it
that you suggested I try a on-line seed file for 'scan', etc? If so, afraid
I've not tried that yet as I've been busy making use of the HP sig gen I
borrowed. Want to calibrate and check every bit of kit I've got asap in
case my old research group need it back again soon! Don't want to keep it
too long as I may then want to cadge a borrow of a spectrum analyser!
Although if I can crack the 'AGC behaviour' with the 290e I may not need
the analyser. :-)
<sp...@andyfurniss.entadsl.com> wrote:
> Jim Lesurf wrote:
> >
> > I can use a calibrated signal level meter (Fringe electronics) to
> > measure the total DTTV mux powers summed across the UHF band. But that
> > doesn't tell me about any individual mux levels, just the total.
> >
> > I can use a calibrated signal level meter (Fringe electronics) to
> > measure the total DTTV mux powers summed across the UHF band. But that
> > doesn't tell me about any individual mux levels, just the total.
> I've not done anything like that.
> Maybe you could subscribe and ask on linux-media where the devs lurk -
> http://vger.kernel.org/vger-lists.html#linux-media
Thanks. I'll start with a poke around their archives to see if I can spot
> Maybe you could subscribe and ask on linux-media where the devs lurk -
> http://vger.kernel.org/vger-lists.html#linux-media
any clues. My confidence in getting fixes from dev lists is low because I
never got much from that for ALSA and had to experiment and DIY/hack my own
way to solutions to problems! But the above group may be much more
responsive.
I was sort-of hoping the bottleneck was in something like tzap that I could
get the source for and tweak. Never done anything at the kernel module
level beyond a bit of basic param changing, etc.
> From seeing this in dmesg
> tda18271: performing RF tracking filter calibration tda18271: RF
> tracking filter calibration complete
> it looks like the 290e uses this as a tuner -
> www.nxp.com/documents/data_sheet/TDA18271HD.pdf
> and modinfo shows you can turn up debugging level -
> root@noki:/home/andy# modinfo tda18271 filename:
> /lib/modules/3.5.3/kernel/drivers/media/common/tuners/tda18271.ko
> version: 0.4 license: GPL author: Michael Krufky
> <mkr...@linuxtv.org> description: NXP TDA18271HD analog / digital
> tuner driver srcversion: 9D1491670F3B32E558D111C depends: intree:
> Y vermagic: 3.5.3 SMP preempt mod_unload PENTIUMIII parm:
> debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
> (or-able)) (int) parm: cal:perform RF tracking filter
> calibration on startup (int)
changes. I'll do some searching to see if I can find an explanation I can
follow.
> PS Did you see my reply to "What the FEC?" I was using a different
> server and am not sure how well it propagated (though it made it to
> Google).
that you suggested I try a on-line seed file for 'scan', etc? If so, afraid
I've not tried that yet as I've been busy making use of the HP sig gen I
borrowed. Want to calibrate and check every bit of kit I've got asap in
case my old research group need it back again soon! Don't want to keep it
too long as I may then want to cadge a borrow of a spectrum analyser!
Although if I can crack the 'AGC behaviour' with the 290e I may not need
the analyser. :-)
Johann Klammer
Oct 19, 2012, 6:52:22 AM10/19/12
to
Jim Lesurf wrote:
>
> Is the problem likely to be in the kernel modules, or in tzap? I was hoping
> it was tzap so that I might be able to write a tweaked version. :-) Alas,
> kernel modules are - so far - well beyond what I've managed to understand
> beyond the general level.
>
> Slainte,
>
> Jim
>
The linux Kernel supplies some filedescriptors for reading TS packets,
>
> Is the problem likely to be in the kernel modules, or in tzap? I was hoping
> it was tzap so that I might be able to write a tweaked version. :-) Alas,
> kernel modules are - so far - well beyond what I've managed to understand
> beyond the general level.
>
> Slainte,
>
> Jim
>
unpacked PES and section data. I do not think tzap would be able to get
any relevant signal data from those.
There are also a whole lot of ioctls for controlling/querying the frontend.
Those relevant for signal quality are:
FE_READ_STATUS
FE_READ_BER
FE_READ_SIGNAL_STRENGTH
FE_READ_UNCORRECTED_BLOCKS
FE_READ_SNR
Not all of those are always implemented(may return ENOSYS or similar)
You can use strace to find out what kernel level function calls tzap
uses(and what is being returned).
Jim Lesurf
Oct 19, 2012, 7:12:50 AM10/19/12
to
In article <508130e6$0$18682$91ce...@newsreader03.highway.telekom.at>,
(level) snr, etc. Does it call and report the above? If so,can you/someone
point me at how to do this or alter the settings given to the module, etc,
whilst working? Afraid this is a level I'm currently ignorant about!
> Not all of those are always implemented(may return ENOSYS or similar)
> You can use strace to find out what kernel level function calls tzap
> uses(and what is being returned).
Again, I'll have to try and find out about that as I've never done it
before! :-)
Johann Klammer <klam...@NOSPAM.a1.net> wrote:
> Jim Lesurf wrote:
> >
> > Is the problem likely to be in the kernel modules, or in tzap? I was
> > hoping it was tzap so that I might be able to write a tweaked version.
> > :-) Alas, kernel modules are - so far - well beyond what I've managed
> > to understand beyond the general level.
> Jim Lesurf wrote:
> >
> > Is the problem likely to be in the kernel modules, or in tzap? I was
> > hoping it was tzap so that I might be able to write a tweaked version.
> > :-) Alas, kernel modules are - so far - well beyond what I've managed
> > to understand beyond the general level.
> The linux Kernel supplies some filedescriptors for reading TS packets,
> unpacked PES and section data. I do not think tzap would be able to get
> any relevant signal data from those. There are also a whole lot of
> ioctls for controlling/querying the frontend.
> Those relevant for signal quality are:
> FE_READ_STATUS
> FE_READ_BER
> FE_READ_SIGNAL_STRENGTH
> FE_READ_UNCORRECTED_BLOCKS
> FE_READ_SNR
I'm wondering how tzap gets the values it lists once per second for signal
> unpacked PES and section data. I do not think tzap would be able to get
> any relevant signal data from those. There are also a whole lot of
> ioctls for controlling/querying the frontend.
> Those relevant for signal quality are:
> FE_READ_STATUS
> FE_READ_BER
> FE_READ_SIGNAL_STRENGTH
> FE_READ_UNCORRECTED_BLOCKS
> FE_READ_SNR
(level) snr, etc. Does it call and report the above? If so,can you/someone
point me at how to do this or alter the settings given to the module, etc,
whilst working? Afraid this is a level I'm currently ignorant about!
> Not all of those are always implemented(may return ENOSYS or similar)
> You can use strace to find out what kernel level function calls tzap
> uses(and what is being returned).
before! :-)
Johann Klammer
Oct 19, 2012, 8:19:55 AM10/19/12
to
Jim Lesurf wrote:
> In article<508130e6$0$18682$91ce...@newsreader03.highway.telekom.at>,
> Johann Klammer<klam...@NOSPAM.a1.net> wrote:
>> Jim Lesurf wrote:
>>>
>>> Is the problem likely to be in the kernel modules, or in tzap? I was
>>> hoping it was tzap so that I might be able to write a tweaked version.
>>> :-) Alas, kernel modules are - so far - well beyond what I've managed
>>> to understand beyond the general level.
>
>
>> The linux Kernel supplies some filedescriptors for reading TS packets,
>> unpacked PES and section data. I do not think tzap would be able to get
>> any relevant signal data from those. There are also a whole lot of
>> ioctls for controlling/querying the frontend.
>
>> Those relevant for signal quality are:
>> FE_READ_STATUS
>> FE_READ_BER
>> FE_READ_SIGNAL_STRENGTH
>> FE_READ_UNCORRECTED_BLOCKS
>> FE_READ_SNR
>
> I'm wondering how tzap gets the values it lists once per second for signal
> (level) snr, etc. Does it call and report the above? If so,can you/someone
Very likely. probably something like this.
> In article<508130e6$0$18682$91ce...@newsreader03.highway.telekom.at>,
> Johann Klammer<klam...@NOSPAM.a1.net> wrote:
>> Jim Lesurf wrote:
>>>
>>> Is the problem likely to be in the kernel modules, or in tzap? I was
>>> hoping it was tzap so that I might be able to write a tweaked version.
>>> :-) Alas, kernel modules are - so far - well beyond what I've managed
>>> to understand beyond the general level.
>
>
>> The linux Kernel supplies some filedescriptors for reading TS packets,
>> unpacked PES and section data. I do not think tzap would be able to get
>> any relevant signal data from those. There are also a whole lot of
>> ioctls for controlling/querying the frontend.
>
>> Those relevant for signal quality are:
>> FE_READ_STATUS
>> FE_READ_BER
>> FE_READ_SIGNAL_STRENGTH
>> FE_READ_UNCORRECTED_BLOCKS
>> FE_READ_SNR
>
> I'm wondering how tzap gets the values it lists once per second for signal
> (level) snr, etc. Does it call and report the above? If so,can you/someone
<code>
int dvbFeStatus(dvb_s *adapter, fe_status_t *status,
unsigned int *ber, unsigned int *strength,
unsigned int *snr, unsigned int *ucblock)
{
uint32_t tempU32;
uint16_t tempU16;
if (status)
{
if (ioctl(adapter->frontend_fd, FE_READ_STATUS, status) < 0)
{
errMsg("FE_READ_STATUS: %s\n", strerror(errno));
return -1;
}
}
if (ber)
{
if(ioctl(adapter->frontend_fd,FE_READ_BER, &tempU32) < 0)
{
errMsg("FE_READ_BER: %s\n", strerror(errno));
*ber = 0xffffffff;
}
else
{
*ber = tempU32;
}
}
if (strength)
{
if(ioctl(adapter->frontend_fd,FE_READ_SIGNAL_STRENGTH,&tempU16)
< 0)
{
errMsg("FE_READ_SIGNAL_STRENGTH: %s\n", strerror(errno));
*strength = 0xffff;
}
else
{
*strength = tempU16;
}
}
if (snr)
{
if(ioctl(adapter->frontend_fd,FE_READ_SNR,&tempU16) < 0)
{
errMsg("FE_READ_SNR: %s\n", strerror(errno));
*snr = 0xffff;
}
else
{
*snr = tempU16;
}
}
if (ucblock)
{
if(ioctl(adapter->frontend_fd,FE_READ_UNCORRECTED_BLOCKS,&tempU32) < 0)
{
errMsg("FE_READ_UNCORRECTED_BLOCKS: %s\n", strerror(errno));
*ucblock = 0xffffffff;
}
else
{
*ucblock = tempU32;
}
}
return 0;
}
<\code>
If you need to know exactly try apg-get source dvb-apps. (Assuming it is
a debian based box).
> point me at how to do this or alter the settings given to the module, etc,
> whilst working? Afraid this is a level I'm currently ignorant about!
>
>> Not all of those are always implemented(may return ENOSYS or similar)
>
>> You can use strace to find out what kernel level function calls tzap
>> uses(and what is being returned).
>
> Again, I'll have to try and find out about that as I've never done it
> before! :-)
>
> Slainte,
>
> Jim
>
The documentation I used were .pdf files called "Linux DVB API Version
> whilst working? Afraid this is a level I'm currently ignorant about!
>
>> Not all of those are always implemented(may return ENOSYS or similar)
>
>> You can use strace to find out what kernel level function calls tzap
>> uses(and what is being returned).
>
> Again, I'll have to try and find out about that as I've never done it
> before! :-)
>
> Slainte,
>
> Jim
>
3" and "Linux DVB API Version 4". filenames: linux-dvb-api-1.0.0.pdf and
linux-dvb-api-v4-0-3.pdf. They should be somewhere on the net... Do not
rely on the specification too much, use kernel headers for definitive
reference. Also, the sources for dvbstream and dvbsnoop are worth reading.
Johann Klammer
Oct 19, 2012, 8:23:42 AM10/19/12
to
Johann Klammer wrote:
> If you need to know exactly try apg-get source dvb-apps. (Assuming it is
^^^^^^^ should be apt-get.
> If you need to know exactly try apg-get source dvb-apps. (Assuming it is
Jim Lesurf
Oct 19, 2012, 11:54:56 AM10/19/12
to
In article <5081456c$0$18695$91ce...@newsreader03.highway.telekom.at>,
> > In
[big snip]
Thanks for the example. :-)
> If you need to know exactly try apg-get source dvb-apps. (Assuming it is
> a debian based box).
I found a tarball which I think comes from the 'Mercurial' site
(dvb-apps-3fc7dfa68484.tar.gz) and I've also been scratching my head over
the code in that. With luck I'll make sense of this sometime before the
effort makes blood emerge from my forehead! ;->
> The documentation I used were .pdf files called "Linux DVB API Version
> 3" and "Linux DVB API Version 4". filenames: linux-dvb-api-1.0.0.pdf and
> linux-dvb-api-v4-0-3.pdf. They should be somewhere on the net... Do not
> rely on the specification too much, use kernel headers for definitive
> reference. Also, the sources for dvbstream and dvbsnoop are worth reading.
Ok, thanks, I'll have a look.
I did another experiment this afternoon. This time I issued a tzap then
used an attenuator to wind down the UHF signal level whilst this was
running and logging. At high powers the 'signal' value (for 'bbc one scot')
actually went *up* a little as I turned down the level. I was using a UHF
splitter to monitor the level. Eventually the signal values output from
tzap started to fall, as I started getting some non-zero 'ber' values. Over
about a 3dB range of further drop this proceeded to change until FEC ceased
to lock. However the levels were *very* low at this point. Probably around
30-40 dBuV, although I can only estimate that indirectly at present.
So the signal levels can be used - a little - to get an idea of the input
level. But they aren't very clear as a guide. Not much more than a 'good'
or 'bad' - and with 'good' and 'bad' values that aren't consistent from one
mux or antenna feed to another! So I will investigate to see if this is a
hardware problem or something odd with tzap, etc, muddling the reports.
> > In
[big snip]
Thanks for the example. :-)
> If you need to know exactly try apg-get source dvb-apps. (Assuming it is
> a debian based box).
(dvb-apps-3fc7dfa68484.tar.gz) and I've also been scratching my head over
the code in that. With luck I'll make sense of this sometime before the
effort makes blood emerge from my forehead! ;->
> The documentation I used were .pdf files called "Linux DVB API Version
> 3" and "Linux DVB API Version 4". filenames: linux-dvb-api-1.0.0.pdf and
> linux-dvb-api-v4-0-3.pdf. They should be somewhere on the net... Do not
> rely on the specification too much, use kernel headers for definitive
> reference. Also, the sources for dvbstream and dvbsnoop are worth reading.
I did another experiment this afternoon. This time I issued a tzap then
used an attenuator to wind down the UHF signal level whilst this was
running and logging. At high powers the 'signal' value (for 'bbc one scot')
actually went *up* a little as I turned down the level. I was using a UHF
splitter to monitor the level. Eventually the signal values output from
tzap started to fall, as I started getting some non-zero 'ber' values. Over
about a 3dB range of further drop this proceeded to change until FEC ceased
to lock. However the levels were *very* low at this point. Probably around
30-40 dBuV, although I can only estimate that indirectly at present.
So the signal levels can be used - a little - to get an idea of the input
level. But they aren't very clear as a guide. Not much more than a 'good'
or 'bad' - and with 'good' and 'bad' values that aren't consistent from one
mux or antenna feed to another! So I will investigate to see if this is a
hardware problem or something odd with tzap, etc, muddling the reports.
Andy Furniss
Oct 19, 2012, 4:24:43 PM10/19/12
to
Jim Lesurf wrote:
>> parm: debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
>> (or-able)) (int)
>> parm: debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
>> (or-able)) (int)
> Afraid at present I don't know how to use that to investigate or make any
> changes. I'll do some searching to see if I can find an explanation I can
> follow.
If you were to load the module manually you could just do -
> changes. I'll do some searching to see if I can find an explanation I can
> follow.
modprobe tda18271 debug=X
where X is one of the the above or the sum of the ones you want - I
don't know what they do but if it were me I'd turn them all on with
debug=31 and see what appears in dmesg/logs.
As the module autoloads you'll need to put
tda18271 debug=X
in some file somewhere in /etc then regenerate something.
Someone will tell you - as I use old LFS so I don't know exactly what
you need to do for Xubuntu.
>> PS Did you see my reply to "What the FEC?" I was using a different
>> server and am not sure how well it propagated (though it made it to
>> Google).
>
> I think I did. But I can't now recall as I've forgotten the details. Was it
> that you suggested I try a on-line seed file for 'scan', etc?
Tony Houghton
Oct 20, 2012, 8:33:03 AM10/20/12
to
In <k5sd0d$7pb$1...@localhost.localdomain>,
sudo depmod -a
sudo update-initramfs -k all -u
The filename doesn't necessarily have to match the module it affects and
the depmod is probably unnecessary. update-initramfs makes sure the
option will apply if the module is loaded very early in the boot
sequence.
--
TH * http://www.realh.co.uk
Andy Furniss <sp...@andyfurniss.entadsl.com> wrote:
> Jim Lesurf wrote:
>
>>> parm: debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
>>> (or-able)) (int)
>
>> Afraid at present I don't know how to use that to investigate or make any
>> changes. I'll do some searching to see if I can find an explanation I can
>> follow.
>
> If you were to load the module manually you could just do -
>
> modprobe tda18271 debug=X
>
> where X is one of the the above or the sum of the ones you want - I
> don't know what they do but if it were me I'd turn them all on with
> debug=31 and see what appears in dmesg/logs.
>
> As the module autoloads you'll need to put
>
> tda18271 debug=X
>
> in some file somewhere in /etc then regenerate something.
>
> Someone will tell you - as I use old LFS so I don't know exactly what
> you need to do for Xubuntu.
sudo echo options tda18271 debug=31 > /etc/modprobe.d/tda18271
> Jim Lesurf wrote:
>
>>> parm: debug:set debug level (info=1, map=2, reg=4, adv=8, cal=16
>>> (or-able)) (int)
>
>> Afraid at present I don't know how to use that to investigate or make any
>> changes. I'll do some searching to see if I can find an explanation I can
>> follow.
>
> If you were to load the module manually you could just do -
>
> modprobe tda18271 debug=X
>
> where X is one of the the above or the sum of the ones you want - I
> don't know what they do but if it were me I'd turn them all on with
> debug=31 and see what appears in dmesg/logs.
>
> As the module autoloads you'll need to put
>
> tda18271 debug=X
>
> in some file somewhere in /etc then regenerate something.
>
> Someone will tell you - as I use old LFS so I don't know exactly what
> you need to do for Xubuntu.
sudo depmod -a
sudo update-initramfs -k all -u
The filename doesn't necessarily have to match the module it affects and
the depmod is probably unnecessary. update-initramfs makes sure the
option will apply if the module is loaded very early in the boot
sequence.
--
TH * http://www.realh.co.uk
Jim Lesurf
Oct 21, 2012, 4:29:09 AM10/21/12
to
In article <slrnk856...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
wrote:
[snip]
> sudo echo options tda18271 debug=31 > /etc/modprobe.d/tda18271 sudo
> depmod -a sudo update-initramfs -k all -u
> The filename doesn't necessarily have to match the module it affects and
> the depmod is probably unnecessary. update-initramfs makes sure the
> option will apply if the module is loaded very early in the boot
> sequence.
Thanks for the info you/others have provided. The more I've looked into
what the tzap does (using my install of Xubuntu), the more it looks like
values are being misreported. For example, I've just noticed that the wiki
page on zap
http://www.linuxtv.org/wiki/index.php/Zap
says that I could expect the snr values to be above 0x8000 for 'good'
reception. I never get values above a few hundred, even when I know the
signal is 20 - 30dB above threshold! FWIW I did some tests again yesterday
where I used an attenuator and splitter, and from the readings on a Fringe
power meter I estimate I can cut the level by more like 40 - 50dB from the
usual input from that particular antenna feed before I get non-zero ber
values or loss of FEC LOCK.
That said, one possible reason is that here the muxes are all 'paired' in
adjacent channels. So if the 290e is estimating snr by including power from
adjacent channels the value will always be boogered by the adjacent channel
mux being regarded as 'noise'. Perils of 'silicon tuners' having lousy RF
designs, perhaps... That said, the 290e seems very sensitive in the absence
of significant interference.
During the upper part of such a range the tzap reported signal level can go
*up* as I wind down the UHF signal level. The snr value is generally around
250 (decimal). Never anything like 0x8000 although it does often go above
about 256 (decimal). I get the impression the limit of what tzap can report
for snr with my 290e would be 0x1FF.
Still unable to determine if the problems are with the hardware, module, or
in tzap, though. Maybe this is like the problem I had a while ago with the
distro version of FFMPEG. [1] I'll keep poking about, experimenting, and
reading...
Slainte,
Jim
[1] That was that the version of ffmpeg in the standard distro repositories
for Xubuntu 11.10 falls over if given a transport stream file that changes
between 5.1 and stereo at some point(s) during the file. I think it was
Andy who suggested I try the 'current' version of FFMPEG. Happy to say,
that works nicely. :-) Maybe the situation with tzap is similar...
wrote:
[snip]
> sudo echo options tda18271 debug=31 > /etc/modprobe.d/tda18271 sudo
> depmod -a sudo update-initramfs -k all -u
> The filename doesn't necessarily have to match the module it affects and
> the depmod is probably unnecessary. update-initramfs makes sure the
> option will apply if the module is loaded very early in the boot
> sequence.
what the tzap does (using my install of Xubuntu), the more it looks like
values are being misreported. For example, I've just noticed that the wiki
page on zap
http://www.linuxtv.org/wiki/index.php/Zap
says that I could expect the snr values to be above 0x8000 for 'good'
reception. I never get values above a few hundred, even when I know the
signal is 20 - 30dB above threshold! FWIW I did some tests again yesterday
where I used an attenuator and splitter, and from the readings on a Fringe
power meter I estimate I can cut the level by more like 40 - 50dB from the
usual input from that particular antenna feed before I get non-zero ber
values or loss of FEC LOCK.
That said, one possible reason is that here the muxes are all 'paired' in
adjacent channels. So if the 290e is estimating snr by including power from
adjacent channels the value will always be boogered by the adjacent channel
mux being regarded as 'noise'. Perils of 'silicon tuners' having lousy RF
designs, perhaps... That said, the 290e seems very sensitive in the absence
of significant interference.
During the upper part of such a range the tzap reported signal level can go
*up* as I wind down the UHF signal level. The snr value is generally around
250 (decimal). Never anything like 0x8000 although it does often go above
about 256 (decimal). I get the impression the limit of what tzap can report
for snr with my 290e would be 0x1FF.
Still unable to determine if the problems are with the hardware, module, or
in tzap, though. Maybe this is like the problem I had a while ago with the
distro version of FFMPEG. [1] I'll keep poking about, experimenting, and
reading...
Slainte,
Jim
[1] That was that the version of ffmpeg in the standard distro repositories
for Xubuntu 11.10 falls over if given a transport stream file that changes
between 5.1 and stereo at some point(s) during the file. I think it was
Andy who suggested I try the 'current' version of FFMPEG. Happy to say,
that works nicely. :-) Maybe the situation with tzap is similar...
Andy Furniss
Oct 21, 2012, 5:13:22 AM10/21/12
to
Jim Lesurf wrote:
> During the upper part of such a range the tzap reported signal level can go
> *up* as I wind down the UHF signal level. The snr value is generally around
> 250 (decimal). Never anything like 0x8000 although it does often go above
> about 256 (decimal). I get the impression the limit of what tzap can report
> for snr with my 290e would be 0x1FF.
I know nothing about rf receivers, but there are several AGC stages in
> During the upper part of such a range the tzap reported signal level can go
> *up* as I wind down the UHF signal level. The snr value is generally around
> 250 (decimal). Never anything like 0x8000 although it does often go above
> about 256 (decimal). I get the impression the limit of what tzap can report
> for snr with my 290e would be 0x1FF.
the tuner datasheet, maybe reducing the signal trips one of those to put
out more.
I don't even know which chip actually is reporting the stats - maybe
it's the Sony demod, which has an AGC block pointing at the tuner.
www.sony.net/Products/SC-HP/cx_news/vol60/pdf/cxd2820r.pdf
Jim Lesurf
Oct 21, 2012, 7:02:15 AM10/21/12
to
In article <k60edm$a07$1...@localhost.localdomain>, Andy Furniss
is wideband it would prevent each mux being able to give a reliable result
for signal size as everything would always be prescaled to the total power
of all the muxes being presented.
> I don't even know which chip actually is reporting the stats - maybe
> it's the Sony demod, which has an AGC block pointing at the tuner.
> www.sony.net/Products/SC-HP/cx_news/vol60/pdf/cxd2820r.pdf
Thanks. Some time ago when first experimenting with the 290e I recall some
command or other returning a string that said it was a 'Sony' tuner device.
but, annoyingly, I can't now recall what did that!
If I use lsusb -v it seems to not really recognise the tuner. The result
starts with
ID 2013:924f Unknown (Pinnacle?)
IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem is
that my systems are mis-indentifying the tuner to the extent that although
it still happily acts as a reciever/decoder the values for things like
signal level are garbled.
Slainte,
Jim
<sp...@andyfurniss.entadsl.com> wrote:
> Jim Lesurf wrote:
> > During the upper part of such a range the tzap reported signal level
> > can go *up* as I wind down the UHF signal level. The snr value is
> > generally around 250 (decimal). Never anything like 0x8000 although it
> > does often go above about 256 (decimal). I get the impression the
> > limit of what tzap can report for snr with my 290e would be 0x1FF.
> I know nothing about rf receivers, but there are several AGC stages in
> the tuner datasheet, maybe reducing the signal trips one of those to put
> out more.
That's my suspiscion. If there is an AGC around a front-end RF stage that
> Jim Lesurf wrote:
> > During the upper part of such a range the tzap reported signal level
> > can go *up* as I wind down the UHF signal level. The snr value is
> > generally around 250 (decimal). Never anything like 0x8000 although it
> > does often go above about 256 (decimal). I get the impression the
> > limit of what tzap can report for snr with my 290e would be 0x1FF.
> I know nothing about rf receivers, but there are several AGC stages in
> the tuner datasheet, maybe reducing the signal trips one of those to put
> out more.
is wideband it would prevent each mux being able to give a reliable result
for signal size as everything would always be prescaled to the total power
of all the muxes being presented.
> I don't even know which chip actually is reporting the stats - maybe
> it's the Sony demod, which has an AGC block pointing at the tuner.
> www.sony.net/Products/SC-HP/cx_news/vol60/pdf/cxd2820r.pdf
command or other returning a string that said it was a 'Sony' tuner device.
but, annoyingly, I can't now recall what did that!
If I use lsusb -v it seems to not really recognise the tuner. The result
starts with
ID 2013:924f Unknown (Pinnacle?)
IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem is
that my systems are mis-indentifying the tuner to the extent that although
it still happily acts as a reciever/decoder the values for things like
signal level are garbled.
Slainte,
Jim
Jim Lesurf
Oct 21, 2012, 7:55:09 AM10/21/12
to
I've been looking around to see what I might be able to get in terms of a
USB VNA/spectrum analyser.
The VNWA3 from http://www.sdr-kits.net/ looks very promising in terms of
specs. But seems to be "Windows Only" so far as supplied software is
concerned. The closest it gets to any Linux useability "use Wine" but with
the provisio that the user needs to have sorted out whatever would be
needed to make the relevant USB connection. Since I've never used Wine I
wonder if anyone knows how easy that would be. (I'm also assuming Wine
doesn't need me to actually install Windows!) Or if anyone has successfully
got the VNWA3 working directly with Linux? I've been doing a web search but
not found any answer as yet to the last question, which isn't encouraging
as I'd want to be able to write/modify the software to make the device work
in ways I'd prefer. For me, that is the whole point of a USB and software
controlled instrument!
I've also emailed sdr-kits and asked them about this. But I suspect I'll
get an answer along the lines of "Windows is all we know or care about,
chum..."
The mRS minVNA series does I work with Linux, but seems to be to be less
capable, and more costly/fiddly to reach >= 1GHz. Not yet found anything
else as promising in performance terms as the VNWA3.
USB VNA/spectrum analyser.
The VNWA3 from http://www.sdr-kits.net/ looks very promising in terms of
specs. But seems to be "Windows Only" so far as supplied software is
concerned. The closest it gets to any Linux useability "use Wine" but with
the provisio that the user needs to have sorted out whatever would be
needed to make the relevant USB connection. Since I've never used Wine I
wonder if anyone knows how easy that would be. (I'm also assuming Wine
doesn't need me to actually install Windows!) Or if anyone has successfully
got the VNWA3 working directly with Linux? I've been doing a web search but
not found any answer as yet to the last question, which isn't encouraging
as I'd want to be able to write/modify the software to make the device work
in ways I'd prefer. For me, that is the whole point of a USB and software
controlled instrument!
I've also emailed sdr-kits and asked them about this. But I suspect I'll
get an answer along the lines of "Windows is all we know or care about,
chum..."
The mRS minVNA series does I work with Linux, but seems to be to be less
capable, and more costly/fiddly to reach >= 1GHz. Not yet found anything
else as promising in performance terms as the VNWA3.
Tony Houghton
Oct 21, 2012, 8:20:21 AM10/21/12
to
In <52e2191...@audiomisc.co.uk>,
3.5.something which is probably newer than yours.
> IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem is
> that my systems are mis-indentifying the tuner to the extent that although
> it still happily acts as a reciever/decoder the values for things like
> signal level are garbled.
Pinnacle was PCTV's old name, I think it was only changed recently,
since the 290e was released.
Jim Lesurf <no...@audiomisc.co.uk> wrote:
> If I use lsusb -v it seems to not really recognise the tuner. The result
> starts with
>
> ID 2013:924f Unknown (Pinnacle?)
I get "ID 2013:024f PCTV Systems nanoStick T2 290e", but my kernel is
> If I use lsusb -v it seems to not really recognise the tuner. The result
> starts with
>
> ID 2013:924f Unknown (Pinnacle?)
3.5.something which is probably newer than yours.
> IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem is
> that my systems are mis-indentifying the tuner to the extent that although
> it still happily acts as a reciever/decoder the values for things like
> signal level are garbled.
since the 290e was released.
Jim Lesurf
Oct 21, 2012, 10:40:52 AM10/21/12
to
In article <slrnk87q...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
wrote:
> > IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem
> > is that my systems are mis-indentifying the tuner to the extent that
> > although it still happily acts as a reciever/decoder the values for
> > things like signal level are garbled.
> Pinnacle was PCTV's old name, I think it was only changed recently,
> since the 290e was released.
Ah! Wonder if this is why I get the problem with signal and snr values...
wrote:
> In <52e2191...@audiomisc.co.uk>, Jim Lesurf <no...@audiomisc.co.uk>
> wrote:
> > If I use lsusb -v it seems to not really recognise the tuner. The
> > result starts with
> >
> > ID 2013:924f Unknown (Pinnacle?)
> I get "ID 2013:024f PCTV Systems nanoStick T2 290e", but my kernel is
> 3.5.something which is probably newer than yours.
Yes. 3.0.0.26 here.
> wrote:
> > If I use lsusb -v it seems to not really recognise the tuner. The
> > result starts with
> >
> > ID 2013:924f Unknown (Pinnacle?)
> I get "ID 2013:024f PCTV Systems nanoStick T2 290e", but my kernel is
> 3.5.something which is probably newer than yours.
> > IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem
> > is that my systems are mis-indentifying the tuner to the extent that
> > although it still happily acts as a reciever/decoder the values for
> > things like signal level are garbled.
> Pinnacle was PCTV's old name, I think it was only changed recently,
> since the 290e was released.
Andy Furniss
Oct 21, 2012, 3:10:16 PM10/21/12
to
Jim Lesurf wrote:
> Thanks. Some time ago when first experimenting with the 290e I recall some
> command or other returning a string that said it was a 'Sony' tuner device.
> but, annoyingly, I can't now recall what did that!
I see Sony in dmesg -
> Thanks. Some time ago when first experimenting with the 290e I recall some
> command or other returning a string that said it was a 'Sony' tuner device.
> but, annoyingly, I can't now recall what did that!
DVB: registering adapter 1 frontend 0 (Sony CXD2820R)...
>
> If I use lsusb -v it seems to not really recognise the tuner. The result
> starts with
>
> ID 2013:924f Unknown (Pinnacle?)
>
> IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem is
> that my systems are mis-indentifying the tuner to the extent that although
> it still happily acts as a reciever/decoder the values for things like
> signal level are garbled.
Assuming you have wget or curl or something like them installed you can
update your usbids by doing as root/sudo
update-usbids
which won't change anything apart from making lsusb match 2013:924f to a
more accurate name.
Tony Houghton
Oct 21, 2012, 4:34:09 PM10/21/12
to
In <52e22d1...@audiomisc.co.uk>,
considerable improvements in the driver between 3.0 and 3.5 I would have
thought.
Jim Lesurf <no...@audiomisc.co.uk> wrote:
> In article <slrnk87q...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
> wrote:
>> In <52e2191...@audiomisc.co.uk>, Jim Lesurf <no...@audiomisc.co.uk>
>> wrote:
>
>> > If I use lsusb -v it seems to not really recognise the tuner. The
>> > result starts with
>> >
>> > ID 2013:924f Unknown (Pinnacle?)
>
>> I get "ID 2013:024f PCTV Systems nanoStick T2 290e", but my kernel is
>> 3.5.something which is probably newer than yours.
>
> Yes. 3.0.0.26 here.
>
>> > IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem
>> > is that my systems are mis-indentifying the tuner to the extent that
>> > although it still happily acts as a reciever/decoder the values for
>> > things like signal level are garbled.
>
>> Pinnacle was PCTV's old name, I think it was only changed recently,
>> since the 290e was released.
>
> Ah! Wonder if this is why I get the problem with signal and snr values...
The name change is irrelevant, but there are likely to have been some
> In article <slrnk87q...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
> wrote:
>> In <52e2191...@audiomisc.co.uk>, Jim Lesurf <no...@audiomisc.co.uk>
>> wrote:
>
>> > If I use lsusb -v it seems to not really recognise the tuner. The
>> > result starts with
>> >
>> > ID 2013:924f Unknown (Pinnacle?)
>
>> I get "ID 2013:024f PCTV Systems nanoStick T2 290e", but my kernel is
>> 3.5.something which is probably newer than yours.
>
> Yes. 3.0.0.26 here.
>
>> > IIRC Pinnacle was an early (DAB?) digital tuner, so maybe the problem
>> > is that my systems are mis-indentifying the tuner to the extent that
>> > although it still happily acts as a reciever/decoder the values for
>> > things like signal level are garbled.
>
>> Pinnacle was PCTV's old name, I think it was only changed recently,
>> since the 290e was released.
>
> Ah! Wonder if this is why I get the problem with signal and snr values...
considerable improvements in the driver between 3.0 and 3.5 I would have
thought.
Jim Lesurf
Oct 22, 2012, 7:00:02 AM10/22/12
to
In article <slrnk88n...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
wrote:
> but there are likely to have been some
> considerable improvements in the driver between 3.0 and 3.5 I would have
> thought.
That was what I was wondering. The "Unknown" may be a sign that various
relevant improvements have been made between 3.0 and 3.5. Which may
explain why I'm not getting sensible signal/snr values reported by tzap.
Although it isn't clear if the problem is with the 'setup' process or with
fetching and processing the values to report correctly.
wrote:
> In <52e22d1...@audiomisc.co.uk>, Jim Lesurf <no...@audiomisc.co.uk>
> wrote:
> >
> >> Pinnacle was PCTV's old name, I think it was only changed recently,
> >> since the 290e was released.
> >
> > Ah! Wonder if this is why I get the problem with signal and snr
> > values...
> The name change is irrelevant,
Indeed. cf below.
> wrote:
> >
> >> Pinnacle was PCTV's old name, I think it was only changed recently,
> >> since the 290e was released.
> >
> > Ah! Wonder if this is why I get the problem with signal and snr
> > values...
> The name change is irrelevant,
> but there are likely to have been some
> considerable improvements in the driver between 3.0 and 3.5 I would have
> thought.
relevant improvements have been made between 3.0 and 3.5. Which may
explain why I'm not getting sensible signal/snr values reported by tzap.
Although it isn't clear if the problem is with the 'setup' process or with
fetching and processing the values to report correctly.
0 new messages