Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Signal Strength / Error correction
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Signal Strength / Error correction
PostPosted: Tue Sep 28, 2004 7:16 pm Reply with quote
kb7oeb
 
Joined: 23 Mar 2004
Posts: 32




I seem to have a lot of corruption in recordings I make with my tuner card. The tool I use to record do not seem to matter. When I run dtvsignal I get 89-94 on all the channels but my recordings still have a lot of errors in either the video or audio.

Any recommendations for better recording or better error correction?

Thanks


Last edited by kb7oeb on Tue Sep 28, 2004 7:23 pm; edited 1 time in total
View user's profile Send private message AIM Address
PostPosted: Tue Sep 28, 2004 7:19 pm Reply with quote
kb7oeb
 
Joined: 23 Mar 2004
Posts: 32




Here is a sample from dtvsignal. When I record from this station its unusual to go more than a minute or so without seeing a glitch (big or small)

/tools/dtvsignal /dev/v4l/video33 17
main: argc 3 argv[1] /dev/v4l/video33
channel 17
freq*16 = 7828
main: ioctl 1 rtn 0
main: ioctl 2 rtn 0
dtvsignal ver 0.1 - by Jack Kelliher (c) 2002
channel = 17 freq*16 = 7828
Signal: | . : . | .____:____.____|
Signal: 091 (047) ##############################
View user's profile Send private message AIM Address
PostPosted: Tue Sep 28, 2004 7:22 pm Reply with quote
kb7oeb
 
Joined: 23 Mar 2004
Posts: 32




This channel is usuall has the fewest glitches in playback. What does the number in the () mean? I have seen it go negative when adjusting the antenna

/tools/dtvsignal /dev/v4l/video33 29
main: argc 3 argv[1] /dev/v4l/video33
channel 29
freq*16 = 8980
main: ioctl 1 rtn 0
main: ioctl 2 rtn 0
dtvsignal ver 0.1 - by Jack Kelliher (c) 2002
channel = 29 freq*16 = 8980
Signal: | . : . | .____:____.____|
Signal: 092 (031) ##############################
View user's profile Send private message AIM Address
Re: Signal Strength / Error correction
PostPosted: Wed Sep 29, 2004 3:52 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Glitching is tuning, buffering or playback.

If red LED on back of card blinks during capture, you're not tuned in good enough, or you're getting so many reflections it's getting errors no matter the antenna adjustment.

You didn't name the capture tools you used, nor the kernel version you're using.

Kernel 2.4.x has issues with spending too much time in cache flush. This is alleviated by using Robert M Love's O_STREAMING patch and opening the ouput file with O_STREAMING flag.

Kernel 2.6.x appears to behave much better and does not require the O_STREAMING fix.

getatsc may not buffer, and may not be multi-threaded, so it could quite easily drop input stream data while waiting on the blocked output write stream data to finish.

dtvstream may have buffers and threads, but I haven't put it under the microscope. The users seem to have favorable comments about it. See recent announcement on this forum.

pchdtvr has buffers, threads, timers and tuner. I've recently added some signal logging to it, so that it is easier to tell if the capture was good, long after the capture is complete. See recent announcement also on this forum.

You didn't mention what you're using for playback, but I noticed the default xine-hd install uses 256 for video buffers in setup.

I use 2048 since 256 gives periodic glitches. mplayer probably has a similar setting.

One last gotcha might be DMA disabled on the drive so the writes are really slow.

dtvsignal # in () is pre-EQ filter input level, or so I've been told. The value outside is the post-EQ filter output level. Sometimes the input level is very low (negative), but the output level is high and stable.

I attribute this to the fancy ATSC electronics that possibly do live up to hype and give 23dB gain. Or my math is REALLY messed up.

Cheers!


kb7oeb wrote:
I seem to have a lot of corruption in recordings I make with my tuner card. The tool I use to record do not seem to matter. When I run dtvsignal I get 89-94 on all the channels but my recordings still have a lot of errors in either the video or audio.

Any recommendations for better recording or better error correction?

Thanks
View user's profile Send private message
PostPosted: Wed Sep 29, 2004 10:20 am Reply with quote
kb7oeb
 
Joined: 23 Mar 2004
Posts: 32




I have read about DBS and that they use FEC forward error correction that can be adjusted. Does ATSC work the same way? Could some stations be providing more error correction than others. Also i wondered where this is done, is the error correction done in hardware or software? I have watched my card and the red light blinks rarely.

I am using 2.4.27, I haven't tried 2.6 yet but I can give it a shot.

To capture I normally use mythtv or dtvstream, I can't get pchdtvr to compile.

For playback I have been using either mplayer or mythtv. Mplayer seems to play back better until it hits an error in the file, usually the video with have corrupted blocks all over the video for a second and the sound gets screwed up for about 10 seconds or so and then playback will stop. What I do when I hit a bad spot is use the mouse wheel to jump ahead and then I wait about 3 seconds and then jump back to just after the bad spot in the file and then it plays fine.

Mythtv is is much better about it but I can't get it to play 1080i very well. Plays 720p or 480i ok , when it hits a bad spot the sound usually clicks and some corrupted video. It recovers on its own unlike mplayer but it happens at least once a minute. I don't think its a performance problem because it happens on 480i video too. I receive 3 stations that send a low bandwidth SD sub channel.

I haven't tried xine very much, its very unstable for me, half the time going to the menu to open a file causes the program to quit.

Should I worry about the number in the ()?

Thanks for the info
View user's profile Send private message AIM Address
glitches
PostPosted: Wed Sep 29, 2004 8:26 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Signal strength:

One thing you might want to check is the output power from your station versus the distance. Since you say the red LED does blink during capture, however often, you're getting some reception glitching.

Duration is a factor as well, if it's blinking faintly, you see little glitches, but if it goes solid red for a second or two, the player has a good chance of getting lost.

If I recall, 92 is a good signal with dtvsignal.

Both numbers are useful for finding the beam, but due to the advanced filters in HD-2000, the number in () is not as important.

I didn't like unit scale in dtvsignal so pchdtvr uses the raw values. 0 to 255 for both seemed more meaningful in finding a good signal.

Look at FCC website and put in callsign then click on facility ID to get detailed info.

http://www.fcc.gov/mb/video/tvq.html

ERP is effective radiating power. The polar charts are pretty interesting as well, 0 is north, so you can figure out where the transmitter is, and which part of which lobe you're getting.

KPXB here has 9.5kW ERP on ATSC. FCC says they are licensed, i.e. LIC instead of CP for Construction Permit. I can get a green LED, but because their power is so low, I need ideal propagation for the red LED to go out.

I should try again, since lately propagation has been gangbusters, even during the day.

It's already pretty awesome that ATSC needs less than half the ERP for an image that's 100 times better. Most ATSC stations here are 1000kW ERP for ATSC, but 2 to 5 times that for NTSC.



Error detection:

It's done in hardware. Reed-Solomon is error method. The red LED is the Reed-Solomon error light. The green one is carrier, as far as I can tell. All stations by mandate should use the same methods, or else it isn't ATSC.

It's also done in software. I have not yet read enough ATSC documentation to know how to do the error detection in software.

I've assumed from other discussions that the packets do have a CRC, but I haven't yet done any work on CRC detection for pchdtvr.

I was saving that CRC bother for scheduling via PSIP once other stations come online here with PSIP, besides CBS, but I may push it to top of the TODO list if it could possibly help captures be more reliable.

There does seem to be a lack of robustness in the input parsers of the various player, but you'll have to admit, it's pretty hard to parse junk, eh?

A bad CRC packet tosser might help, but does it go in the capture tool or does it go in the player?

Remember that you want the capture tool to be as fast as possible to prevent the HD-2000 DMA buffers from over-running. They're gonna overwrite regardless of the CPU being there to empty it. Nature of the interrupt driven DMA controller beast. So keep it fast, don't bog it down. Bad CRC packet tosser on FIFO empty thread could cause some interesting variable latencies.

Perhaps the player is better equipped to deal with, and should be the thing that does deal with, such timing issues.

It becomes a timing issue simply because the player has to be able to keep its internal clock running so it can pick up where it left off when the stream returns to normal.

This is the reason why pchdtvr caps full streams, errors and all, so the player can at least use the bitrate of the bad stream data to keep the input bit timer going. It's a good theory, at least. :>



Error correction:

I haven't seen much about that. As radio is a naturally lossy medium, it seems the MPEG Transport Stream with redundant information is the only method currently employed.

FEC might have onerous patent licensing that the ATSC kept out of the specification, but I'll admit that's pure speculation.



Kernel 2.4.x:

Other than the RS errors, it's most likely the write cache buffer flush latency is too high in 2.4.27. It refuses to give up enough CPU when it's off on a 100MB write cache buffer flush. That's about 2 seconds even on a 50MB/sec drive.

Super fat glitch for ATSC.

Most players go to la-la land with drop-outs of that magnitude.

As far as I know, RML's O_STREAMING patch never made it to main kernel, but it can be found in his people directory on the mirrors.

I guess I should post the O_STREAMING patch alongside the 2.4.26 stuff on nop.org, eh? I think I forgot to do that. Whoops.

I've been using the RML O_STREAMING patch since I noticed it fixed some issues for my zoran player code, way back 2.4.16 I think.

I switched to the 2.4.20 patch after 2.4.19 shakeup. I think the 2.4.20 O_STREAMING patch applies cleanly, with only offset messages and no rejects, for the later 2.4.x kernels.

Even a multi-threaded FIFO didn't address the issue adequately. I know because I fought this battle while developing pchdtvr.

Multi-thread and FIFO got me part way there, and O_STREAMING conquered the glitch beast.

As far as I know, dtvstream is multi-thread and has a FIFO, maybe dual, can't recall spec. So you have most of the pieces for 2.4.x to work.

Only need O_STREAMING patch, if you have to keep using 2.4.x for whatever reason. That and patch the source for the capture tool to open the output as O_STREAMING.

So as you see, there are some minor stumbling blocks for 2.4.x capture, but as you will see soon, they pretty much go away for 2.6.x.



Kernel 2.6.x:

After using 2.6.7 for a couple of months now, I can recommend it over 2.4.x. No need for O_STREAMING patch being the main reason.

dtvstream should work fine on 2.6.x, and captures at least should be glitch-free, if the baleful eye of the RS error LED doesn't light.

Kinda reminds me of HAL 9000:
"Dave, I am experiencing a loss of signal."

pchdtvr works great on 2.6.7 , but it also works great on 2.4.26 with O_STREAMING patch.

2.6.x has shorter timeslice, and probably other improvements that reduce the latency of the write cache buffer flush. The cache values from /bin/free are always maxed, so the memory usage isn't as restrained during capture as it is with 2.4.x and O_STREAMING.

It's probably only an optical illusion, but it seems playback during capture with 2.6.x is more fluid on pans than with 2.4.x, but there are vast differences between the distributions used, old gcc vs new gcc, old X vs new X, etc.



pchdtvr:

Couldn't compile it, eh? Thought I'd fixed all the compilation bugs, but I'm interested in seeing what my latest code gives for errors.

Latest may be found at:
http://www.nop.org/inkling/dtv
kernel patches are required now for the LED sense, so apply to appropriate vanilla.

You could do this to 2.6.7 as it seems to work, and you seem to be able to give 2.6.7 a go.

Post full output from compile attempt please? Instructions for compiling can be found at the top of pchdtvr.c file.

pchdtvr has the most common things I know to fix any buffer over-runs and under-runs during capture. The latest version will generate a .stat file after capture to show how many red LED's it caught. It only checks once per second so it's a rough estimate, at best. It won't find flickers, but you can tell if the file is really bad from a screen of text.

I don't see any periodic glitching, using pchdtvr and xine-hd for playback, unless the red LED gets to flickering.

I can only surmise the streams are probably getting captured as near as glitch-free as can easily be done from a lossy radio medium feeding a non-real-time operating system.

I was getting glitches last week, couldn't figure out why, but then finally remembered I erased my xine config and had to go set video buffers back to 2048 from 256 default.

Doh!


xine:

xine-hd can be a bit tricky to get installed correctly. I had to jump thru a few hoops for new gentoo distro. Finally figured let gentoo install all the stuff for newest xine-lib and xine-ui, then remove only xine-lib and xine-ui and replace with xine-hd stuff.

I did all that and I still didn't have sound.

The problem seemed to be liba52 wasn't being detected and maybe something is missing in internel liba52 it tries to use when it can't find one in .../lib/ dirs. Installing external liba52 lib from latest source fixed the lack of sound.

It's working fine now, even plays DVDs, but I'll admit I never use File Open.

xine-hd also seems to recover from reception audio or video glitches fairly rapidly, but big drop-outs can send it to la-la land just like the other players. So in that regard sometimes it's not any better or any worse than the other players.

I use it because it's simple and does enough.


Sounds like once you get the capture glitches whooped, using any or all of the above, you'll be able to use whatever player you want.

You can stopwatch the glitches. Transfer rate for ATSC is about 2.5 MByte / second. I bet you'll find the hard drive light goes solid for a while and the times that it does coincides with the glitch points in the stream. If it's every 40 seconds, that's every 100MB.

If there's a way to force MythTV to display 1080i as 960x544, try that. I could presume that MythTV is using the same codecs as xine, at least for MPEGv2 and A/52, but that might not be correct.

There are a few papers on handling errors in MPEG Transport Streams. Pretty dry reading, though, unless you're trying to get it done.


Cheers!




kb7oeb wrote:
I have read about DBS and that they use FEC forward error correction that can be adjusted. Does ATSC work the same way? Could some stations be providing more error correction than others. Also i wondered where this is done, is the error correction done in hardware or software? I have watched my card and the red light blinks rarely.

I am using 2.4.27, I haven't tried 2.6 yet but I can give it a shot.

To capture I normally use mythtv or dtvstream, I can't get pchdtvr to compile.

For playback I have been using either mplayer or mythtv. Mplayer seems to play back better until it hits an error in the file, usually the video with have corrupted blocks all over the video for a second and the sound gets screwed up for about 10 seconds or so and then playback will stop. What I do when I hit a bad spot is use the mouse wheel to jump ahead and then I wait about 3 seconds and then jump back to just after the bad spot in the file and then it plays fine.

Mythtv is is much better about it but I can't get it to play 1080i very well. Plays 720p or 480i ok , when it hits a bad spot the sound usually clicks and some corrupted video. It recovers on its own unlike mplayer but it happens at least once a minute. I don't think its a performance problem because it happens on 480i video too. I receive 3 stations that send a low bandwidth SD sub channel.

I haven't tried xine very much, its very unstable for me, half the time going to the menu to open a file causes the program to quit.

Should I worry about the number in the ()?

Thanks for the info
View user's profile Send private message
PostPosted: Sat Oct 02, 2004 8:44 pm Reply with quote
kb7oeb
 
Joined: 23 Mar 2004
Posts: 32




Quote:
I haven't seen much about that. As radio is a naturally lossy medium, it seems the MPEG Transport Stream with redundant information is the only method currently employed.

FEC might have onerous patent licensing that the ATSC kept out of the specification, but I'll admit that's pure speculation.


I think that might be the same thing, in satellite its called FEC but might go by another name with ATSC. Basically with FEC they are sending redundant data to correct errors in the signal. The satellite provider can reduce the amount of redundant data sent so that they can increase video capacity but then it's harder for the receiver to compensate for errors.

Quote:
After using 2.6.7 for a couple of months now, I can recommend it over 2.4.x. No need for O_STREAMING patch being the main reason.


I gave 2.6.7 a shot and man it works great! So far in the few recordings I have made they are problem free. I am using gentoo and the development-sources, as far as I can tell the development-sources are vanilla. I used the patches from your website, from what I could find they were the latest available.

Quote:
pchdtvr:

Couldn't compile it, eh? Thought I'd fixed all the compilation bugs, but I'm interested in seeing what my latest code gives for errors.



Here is what I get when I try and compile, I think it might be because I am using a newer gcc, I am using the videodev.h from your website.

Code:

mythtv@furball pchdtvr-pre5-1.0 $ gcc -Wall -O3 -lpthread pchdtvr.c -o pchdtvr
pchdtvr.c: In function `main':
pchdtvr.c:6056: warning: unused variable `env_display'
pchdtvr.c: At top level:
pchdtvr.c:4209: warning: `get_signal_locks' defined but not used
pchdtvr.c:4376: warning: `order' defined but not used
pchdtvr.c:4383: warning: `order_dump' defined but not used
/tmp/ccxRluqM.o(.text+0x2581): In function `show_signal':
: undefined reference to `log10'
/tmp/ccxRluqM.o(.text+0x25b5): In function `show_signal':
: undefined reference to `log10'
/tmp/ccxRluqM.o(.text+0x25ee): In function `show_signal':
: undefined reference to `log10'
collect2: ld returned 1 exit status


This is my gcc -v

Code:

mythtv@furball pchdtvr-pre5-1.0 $ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.4/specs
Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i586-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i586-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i586-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i586-pc-linux-gnu/3.3/info --enable-shared --host=i586-pc-linux-gnu --target=i586-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)


The only downside so far is that mythtv can't change the channel anymore,I'll have to keep working on that.

Thanks for all your help with this Smile
View user's profile Send private message AIM Address
PostPosted: Sun Oct 03, 2004 7:29 am Reply with quote
Guest
 




kb7oeb wrote:
Quote:
I haven't seen much about that. As radio is a naturally lossy medium, it seems the MPEG Transport Stream with redundant information is the only method currently employed.

FEC might have onerous patent licensing that the ATSC kept out of the specification, but I'll admit that's pure speculation.


I think that might be the same thing, in satellite its called FEC but might go by another name with ATSC.
Its called FEC in ATSC too Very Happy .
Quick examples: you can see that FEC is being performed by the Oren demodulator (PDF) and the Nxt4000 demodulator (Ati HDTV Wonder). Same with all the others...
compile errors
PostPosted: Tue Oct 05, 2004 3:05 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Try compiling with -lm and if that fails try to figure out where log10 is defined. It's in math.h here, and for what ever reason -lm is assumed.


Code:

mythtv@furball pchdtvr-pre5-1.0 $ gcc -Wall -O3 -lpthread pchdtvr.c -o pchdtvr
pchdtvr.c: In function `main':
pchdtvr.c:6056: warning: unused variable `env_display'
pchdtvr.c: At top level:
pchdtvr.c:4209: warning: `get_signal_locks' defined but not used
pchdtvr.c:4376: warning: `order' defined but not used
pchdtvr.c:4383: warning: `order_dump' defined but not used
/tmp/ccxRluqM.o(.text+0x2581): In function `show_signal':
: undefined reference to `log10'
/tmp/ccxRluqM.o(.text+0x25b5): In function `show_signal':
: undefined reference to `log10'
/tmp/ccxRluqM.o(.text+0x25ee): In function `show_signal':
: undefined reference to `log10'
collect2: ld returned 1 exit status


Hmm opposite result changing channels from what someone else had with my barely hacked driver, eh?

Do you think you can hook up with the fellow who posted that my slightly patched driver worked on channel changes for MythTV?

As I don't use MythTV, I can't help you.

You got a real puzzle on your hands.

Best of luck solving it.
View user's profile Send private message
Signal Strength / Error correction
  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 1 of 1  

  
  
 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