Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Specifications for HD-3000? Goto page Previous  1, 2, 3, 4  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
collecting statistical data
PostPosted: Wed Apr 05, 2006 1:09 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Jim wrote:
Unfortunately with our cards we can not see changes on the fly with the signal..It must be perfect or system crashes. Real time strength indicators help, but not by much. We have a ways to go.


Jim,

pchdtvr captures from 3 cards here all the time, through bad signal or good. There are no crashes in pchdtvr and the driver failure caused by non-locked signal strength acquisition has also been addressed, along with a few other problems the driver itself had with i2c reliability.

See this thread for all the gory details:
http://www.pchdtv.com/forum/viewtopic.php?t=1213

pchdtvr generates a capture error log file that will tell you how bad the capture was. I don't use any other capture tools because no other tool than pchdtvr will allow me to collect the statistical data I need in order to make informed theories about why a particular capture has errors.

Seeing signal strength changes "on-the-fly" during capture is not particularly useful, as you may have found out for yourself, unless you plan on building some kind of rotor interface that will act on the data.

My own experiments on reading signal strength during capture show it to be much less than useful. It can actually cause more problems by trying to make the demodulator chip work at the limit of what is probably only a single-tasking ability, even with my fixes to driver.

I theorize that all ATSC cards will have this problem, simply because it would cost more to design a demodulator that could read signal strength absolutely reliably and rapidly during capture. Dual demod/tuners needed for the easy way out, 2x cost, or total redesign of the demodulator chip, at an unknown and probably very large cost.

I can get usable stream down to 45% strength, sometimes, so the signal strength reading is actually worse than a ball-park figure and should be disregarded as an irrelevant data point.

It's much more useful, and informative, to fully process the stream to see how many errors it has. This requires some understanding of the ATSC specification to be able to know when a packet is bad.

I don't know or care what other capture tools do because pchdtvr processes every packet for later statistical analysis.

Typically, there are three ways to tell if the packet (or payload table) is (or will be) bad:

#1) Transport Error Indicator, one bit in the header of each packet. This is generated by the demodulator itself. FEC, Reed-Solomon, Viterbi all play a role in that. Some packets can be corrected by the redundant bits sent in the signal, others are hopeless.

#2) CRC32 computation and comparison against received CRC32. This catches missing/bad packet errors but is only effective for ATSC (MGT VCT EIT ETT) and MPEG tables (PAT PMT), not audio nor video which do not have CRC32.

#3) Continuity Counter. This is a 4 bit counter that increments for each packet type under most conditions. It's not very reliable because it's possible that 16 packets dropped would give no error. This is the only way to tell if the video and audio packets are more or less good, at least until they start sending CRC32 on video and audio.

These are not perfect solutions, but they're about as close as can easily be done. pchdtvr uses all three methods for error determination. Signal strength is checked 4 times at the start of capture in the AOS code and is not checked again.

As for the tuner specifications, you would want the Thompson DTT7610 datasheets or else you would have nothing to compare against your experimentally collected RF data. Without knowing what the expected upper and lower control limits of the data collected should be, any ad-hoc data collected is pretty much useless.

As for the driver, there are some definite problems with what is currently being distributed. I think I have adequately addressed all of the problems, as the HD-3000 driver is now rock-solid at greater than 35 days of continuous operation.

I had to rewrite driver to not check signal strength if there is no signal lock, along with adding the i2c fault-tolerance and fault-recovery reset code.

I discovered that problem long ago with the HD-2000 and at first modified pchdtvr to check the lock status before reading the signal strength.

I have since modified the driver to check the lock condition in the driver signal strength acquisition function because the temporal difference between separate user ioctl for signal lock and user ioctl for signal strength was too large under load to provide accurate signal lock data.

These driver modifications should be useful to anyone, whether they use pchdtvr, MythTV, or any other decent multi-threaded capture tool (cat is not multi-threaded and should not be used as a substitute for a robust capture tool.)

I don't have the datasheets on anything but the cx23883 and bt878a, yet I can read the source code for the other items and figure it out eventually.

It took me a year to collect the data to find the driver problems, but it only took me a month to fix it and the past month testing it.

Be a scientist, collect the data, employ the scientific method, or all that Renaissance crap was for nothing.

"We have a ways to go."

Hey man, I'm already there, waiting on you!

OK, I'm done filibustering.

-ink
View user's profile Send private message
PostPosted: Wed Apr 05, 2006 12:23 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
The cx8800 chip on the HD3000 has docs. The eeprom has docs. The tuner has docs. It's just the demodulator, the critital non-broadcast flag component, which will probably be outlawed, that is top secret.

You're talking about documentation. This thread is about specifications. These are two very different things.
View user's profile Send private message
PostPosted: Wed Apr 05, 2006 2:18 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
xyzzy wrote:
The cx8800 chip on the HD3000 has docs. The eeprom has docs. The tuner has docs. It's just the demodulator, the critital non-broadcast flag component, which will probably be outlawed, that is top secret.

You're talking about documentation. This thread is about specifications. These are two very different things.

In order to test the card's RF ability, it's really the documentation you need.
View user's profile Send private message
RF data collection (tangential distraction)
PostPosted: Wed Apr 05, 2006 6:18 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




xyzzy wrote:
In order to test the card's RF ability, it's really the documentation you need.


It either provides good stream or it doesn't. No amount of RF data collected will change that.

Atmospheric conditions affect photon propagation. One hour before sunset the RF data will look one way, and one hour after sunset the RF data will look different. At 4am when the air is coolest and the photon refraction is greatest, you'll get different data than what you collected before and after sunset.

What you find out is your dependence on RF measurement is a flawed methodology which provides you with completely useless data.

When a good scientist realizes they have a flawed methodology in data collection, the same good scientist will find a better method.

What it boils down to, and all that matters is: can the demodulator do something with that signal?

The only way to know for sure is by inspecting the stream.

Some idealized data from an RF generator will not be representative of ANY real-world scenario.

Are you a good scientist? Are you a good engineer?

If you are neither, please leave it to those of us who are.

-ink
View user's profile Send private message
PostPosted: Wed Apr 05, 2006 7:43 pm Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




inkling wrote:

> Seeing signal strength changes "on-the-fly" during capture is not particularly useful,

Just because you do not find signal strength to be useful doesn't mean it isn't
useful to others.

> trying to make the demodulator chip work at the limit of what is probably only
> a single-tasking ability

probably ?

We need to KNOW what the abilities are.

> As for the driver, there are some definite problems with what is currently being
> distributed.

"currently being distributed" meaning what? 2.6.16 ?

> I had to rewrite driver to not check signal strength if there is no signal lock

Huh? Why? If you are, for example, trying to aim an antenna, you need to know
the signal strength, even if there is no signal lock. Perhaps *especially* if
there is no signal lock.

Yes, signal strength is only a part of the picture. But it is an essential part.

> cat is not multi-threaded

Yeah, so what?

> and should not be used as a substitute for a robust capture tool.

I've seen lots of postings where people say doing the least little thing
hurts the capture. Given this, it seems wise to capture with a simple
utility that uses the minimum amount of resources possible. I use dd
rather than cat.

Or does this "robust capture tool" issue some magic ioctl to fine-tune
some parameter?

> It took me a year to collect the data to find the driver problems, but it
> only took me a month to fix it and the past month testing it.

> Hey man, I'm already there, waiting on you!

So you are not losing lock? Programs like ffmpeg, mplayer, xine
do not complain about your mpeg2ts files?

xyzzy wrote:

> The tuner has docs.

Where ?

Scott Larson wrote:

> You're talking about documentation. This thread is about specifications.
> These are two very different things.

Specifications are a subset of documentation. As the creator of this thread,
I invite pointers to relevant documentation as well as pointers to
specifications.
View user's profile Send private message
PostPosted: Thu Apr 06, 2006 1:26 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dieter wrote:
We need to KNOW what the abilities are.

Who are "we" and why do they need to know? My PC-2000 and PC-3000 correctly receive ATSC broadcasts. A bunch of numbers on a page isn't going to change that and I don't see how it will change how anyone else's card will receive ATSC broadcasts.
View user's profile Send private message
Re: RF data collection (tangential distraction)
PostPosted: Fri Apr 07, 2006 7:14 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




inkling wrote:
xyzzy wrote:
In order to test the card's RF ability, it's really the documentation you need.


It either provides good stream or it doesn't. No amount of RF data collected will change that.

Documentation could tell you why it doesn't work. There is more information in that chip than works/doesn't work and more settings than on and off. It might be possible to take a signal that doesn't work, and make it work. Without docs, who knows?

inkling wrote:

Some idealized data from an RF generator will not be representative of ANY real-world scenario.

Are you a good scientist? Are you a good engineer?

If you are neither, please leave it to those of us who are.

So the entire concept of controlled experiments is a flawed one? Are you capable of civilized discourse? If you are not, please leave it to those of us who are.

inkling wrote:

or any other decent multi-threaded capture tool (cat is not multi-threaded and should not be used as a substitute for a robust capture tool.)

I don't think a mutli-threaded capture tool is needed for the DVB drivers. The DVB driver creates a kernel thread to copy and filter the data out of the cx88 DMA buffers and into the dvr0 device buffer. The dvr0 device has a buffer for about a half second of HD data. So 'cat' effectively is multi-threaded.

dieter wrote:

xyzzy wrote:
> The tuner has docs.
Where ?

I couldn't find docs for the whole Thomson DTT7612 tuner, but there are only two chips in it, Infineon TUA6030 and Philips TDA9887TS, and you can get docs them them easily enough. That tells you pretty much everything you need to know to program the tuner.

Scott Larson wrote:

My PC-2000 and PC-3000 correctly receive ATSC broadcasts. A bunch of numbers on a page isn't going to change that and I don't see how it will change how anyone else's card will receive ATSC broadcasts.

Well my HD-3000 doesn't. I'd like to fix it. It didn't tune to channels around 150 MHz and 450 MHz correctly either, but I fixed that with a few number on a page.
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 8:50 am Reply with quote
Jim
 
Joined: 01 Mar 2005
Posts: 88
Location: Greater Portland ME joined jan'05




Photons? Ah, now I know what those lights on the tv towers are...They are the photon source...I never knew.

_________________
Stars Up, Lights Down... International Darksky Association... Be a good neighbor, shield/turn off your lights.
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 9:13 am Reply with quote
GrepTar
 
Joined: 10 Jan 2005
Posts: 51




Photons are commonly associated with visible light, but this is actually only a very limited part of the electromagnetic spectrum. All electromagnetic radiation is quantized as photons...

http://en.wikipedia.org/wiki/Photon
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 12:19 pm Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




Scott> Who are "we" and why do they need to know?

Anyone who is not getting perfect captures and wants to
improve matters.

Scott> My PC-2000 and PC-3000 correctly receive ATSC broadcasts.

So you can capture all your local stations and never lose lock?
Programs like ffmpeg, mplayer, xine, ..., never complain about the
recorded files?

What is your secret?

How far from the transmitters are you?
What antenna(s) are you using?
Are you using a preamp?
Are you using a FM trap?
Any other traps, or signal modifying filters?

What kernel are you using?
What capture program are you using?

What else do we need to know to duplicate your results that I forgot
to ask about?

xyzzy> I couldn't find docs for the whole Thomson DTT7612 tuner, but there
xyzzy> are only two chips in it, Infineon TUA6030 and Philips TDA9887TS

That's a start. Thank you.
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 7:46 pm Reply with quote
Jim
 
Joined: 01 Mar 2005
Posts: 88
Location: Greater Portland ME joined jan'05




Oh so our cards are using weak force elementary concepts...And I thought UHF was just an alocated electromagnetic band our wonderful friendly candy company let us use for awhile. Maybe this thread says all... we are getting too complicated..KISS method would be better. Or is it strong force..yeah everything can be boiled down to photons...except the 4am morning thing lol.

So can you steer us to the chipset specs? Like how to measure rf strength on the fly? How about the tuner specs, pinout?

_________________
Stars Up, Lights Down... International Darksky Association... Be a good neighbor, shield/turn off your lights.
View user's profile Send private message
Re: RF data collection (tangential distraction)
PostPosted: Sat Apr 08, 2006 11:27 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
Scott Larson wrote:
My PC-2000 and PC-3000 correctly receive ATSC broadcasts. A bunch of numbers on a page isn't going to change that and I don't see how it will change how anyone else's card will receive ATSC broadcasts.

Well my HD-3000 doesn't. I'd like to fix it. It didn't tune to channels around 150 MHz and 450 MHz correctly either, but I fixed that with a few number on a page.

Hmmm, mine already tuned those frequencies just fine. What's your other problem?
View user's profile Send private message
PostPosted: Sat Apr 08, 2006 11:42 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dieter wrote:
Anyone who is not getting perfect captures and wants to
improve matters.

There are many ways to fix this.

Quote:
Scott> My PC-2000 and PC-3000 correctly receive ATSC broadcasts.

So you can capture all your local stations and never lose lock?
Programs like ffmpeg, mplayer, xine, ..., never complain about the
recorded files?

What is your secret?

Yes. I receive every single station in my area pefectly. All my files are perfect, except when a station's transmitter fails which is a constant problem with the O&O WB station.

My secret was getting a Yagi antenna appropriate for my location, only extending the elements I needed to get good reception for all stations (so it won't be too directional) and putting it someplace where it wouldn't get multipath from cars. Yes this was a lot of work and required a lot of experimentation but if you're not down with that, you should use a Windows machine with an HDTV card or stick to cable.

Quote:
How far from the transmitters are you?
What antenna(s) are you using?
Are you using a preamp?
Are you using a FM trap?
Any other traps, or signal modifying filters?

I'm using some Radio Shack Yagi with only two front elements extended. This is because I'm only a few miles from the antenna farm in my area and the two clusters of towers are a few degrees apart so any more elements would have been the antenna too directional. I certainly don't need a preamp at this distance.

The main trick was to get the antenna away from the street so trucks and large vehicles wouldn't cause multipath.

Quote:
What kernel are you using?
What capture program are you using?

2.4.25. I use dtvstream to save the files.

Quote:
What else do we need to know to duplicate your results that I forgot
to ask about?

That depends on what's causing your problems. Most PC-3000 cards aren't having problems although it's very easy to cause problems if you aren't careful about antennas and where you put them.
View user's profile Send private message
Re: RF data collection (tangential distraction)
PostPosted: Sat Apr 08, 2006 12:40 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Scott Larson wrote:
xyzzy wrote:

Well my HD-3000 doesn't. I'd like to fix it. It didn't tune to channels around 150 MHz and 450 MHz correctly either, but I fixed that with a few number on a page.

Hmmm, mine already tuned those frequencies just fine. What's your other problem?


You have cable as well as an antenna? What channels do you get that lead you to believe that you get frequencies near 150 MHz and 450 MHz correctly? Because there are no non-cable channels anywhere near those frequencies.

My other problem is that certain X activity when using the nvidia driver kills digital reception. It appears it's not a PCI or software problem, but something to do with the top-secret demodulator. If I had documentation I could do a lot more.
View user's profile Send private message
Re: RF data collection (tangential distraction)
PostPosted: Sat Apr 08, 2006 9:45 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xyzzy wrote:
You have cable as well as an antenna? What channels do you get that lead you to believe that you get frequencies near 150 MHz and 450 MHz correctly?

Yes, I have cable too. I've used one of the QAM drivers in the past but my cable company doesn't carry enough local channels for me to use it regularly.

Quote:
My other problem is that certain X activity when using the nvidia driver kills digital reception. It appears it's not a PCI or software problem, but something to do with the top-secret demodulator.

And how did you conclude that the demodulator is, uh, incompatible with the Nvidia driver? Lots of us been using them both for over two years. This would be major news to all of us.

Quote:
If I had documentation I could do a lot more.

While you're getting the specs for the top-secret demodulator, why don't you ask Nvidia for the specifications for their top-secret driver? Rolling Eyes
View user's profile Send private message
Specifications for HD-3000?
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 2 of 4  
Goto page Previous  1, 2, 3, 4  Next
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin