Re: [Discuss-gnuradio] ATSC Decode Issues
Getting this conversation back into the discuss-gnuradio thread. Looks like on Kali/debian linux running the latest updates that for some reason the PFB arbitrary resampler is producing the correct number of output samples but incorrect values (confirmed on both Ubuntu and Windows where it works). Also in testing the atsctest.cfile I found that if you install the gr-correctiq module and run the input through that first, you get much more packet data out the other side (500+MB [I stopped it] versus 80 MB without it). For anyone else working on ATSC decoding it may help improve the quality of the output IQ stream. -- Forwarded message -- Sylvain, I've done some more debugging and the mystery only deepens. I Ran the flowgraph in an Ubuntu 14.04LTS VM with both 3.7.10.1 and a fully pybombs updated version and the output worked fine. My original test system is Kali / debian linux fully updated. I added some prints in the pfb_arb_resampler to look at the taps that are used and the numbers all match, however the output bytes are still different. The debugging is getting a bit deeper than my expertise into the filters and pfb code. Nothing jumped out at me as to why the output calculations would be different. Would you be able to fire up a Kali VM to reproduce it? This will get you up and running pretty quickly... There's 2 quick things to do while installing on Kali. First, before starting run 'apt-get install zlib1g-dev'. It's a pre-req that didn't seem to be verified for one of the header files. Next, when pybombs gets to Apache thrift, when it starts to build break the install and edit /src/apache-thrift/ lib/cpp/src/thrift/transport/TSSLSocket.cpp. Search for 'SSLv3_method' and change it to 'SSLv23_method'. Go into the src directory and manually finish the apache thrift build then go back to the pybombs install and everything will run through fine. Now that I know the combo to consistently reproduce the issue that should help hunt it down. Thanks! -- Forwarded message -- From: GhostOp14 <ghosto...@gmail.com> Date: Mon, Apr 24, 2017 at 7:12 AM Subject: Re: [Discuss-gnuradio] ATSC Decode Issues To: Ron Economos <w...@comcast.net> I was playing with the no_pfb version of the flowgraph again now trying to work on getting an input signal to a file and I had a couple of other questions about the ATSC process. Out of curiosity when you removed the PFB resampler you used an FFT filter rather than a FIR filter for the RRC filter. From a signal-processing perspective what makes the FFT the correct choice there rather than a FIR? I was also trying to see if I could adjust the input rate to that 10.7622 Msps with a different resampler if I wanted to use the Airspy instead of my hackrf. If I drop a rational resampler after the throttle block and use the interpolation/decimation to adjust the output rate to 10.7622 I don't get good output (it was worth a shot right?). Any math thought behind why that approach doesn't work? Thanks! On Sun, Apr 23, 2017 at 4:13 PM, GhostOp14 <ghosto...@gmail.com> wrote: > I sent an email to you and Sylvan to see if he could figure it out. > > In the meantime if you want to see where I'm trying to go, if you take the > working flowgraph that successfully produces the output file and go up to > github and download/install this OOT module I'm working on: > https://github.com/ghostop14/gr-atsc2.git. > > Drop the ATSC2 Streaming Server block in place of the output file, set a > port number like 8800 and start the flowgraph. Then open VLC, go under > Media, select "Open Network Stream", put in http:// flowgraph>:8800/ and voila! Streaming output. With the non-PFB flowgraph > I would suspect it'll work in real-time. The TS Stream server block is a > really low utilization block. > > > > On Fri, Apr 21, 2017 at 10:58 PM, Ron Economos <w...@comcast.net> wrote: > >> Bummer! I do have something you can try. It's possible to eliminate the >> PFB resampler from the flow. I've attached a flow graph that uses just an >> RRC filter. The input file sample rate has to be 10.76 Msps, but you can >> create that yourself with the ATSC transmitter (file_atsc_tx.grc). >> >> The test TS file for the ATSC transmitter is here: >> >> http://www.w6rz.net/advatsc.ts >> >> 256,952,572 bytes. >> >> BTW, without the PFB resampler the flow runs much faster. Real-time on my >> modest E5-1607. It's too bad the Airspy can't do fractional sample rates. >> >> That reminds me. On your original flow graph, you had a rational >> resampler. That's not needed, just set the sample_rate to 10 Msps and let >> the PFB resampler do all the work. Also, the low-pass filter isn't >> necessary either. >> >> Ron >> On 04/21/2017 09:04 AM, GhostOp14 wrote: >&g
Re: [Discuss-gnuradio] ATSC Decode Issues
Unless you have a many core CPU (greater than four), the ATSC decoder usually doesn't run in real time. You have to capture an IQ stream to disk first and then demodulate it in non real-time. Ron On 04/19/2017 09:14 AM, Ghost Op wrote: Hi all, I'm having an issue getting ATSC to decode and I was hoping someone who has done it successfully may have some pointers. Here's the scenario Basic SDR antenna connected to an LNA4ALL feeding into an Airspy sampling at 10 MSPS using the attached flowgraph. I get a TS file and don't get any atsc_fs_checker error warnings while capturing, however the TS file doesn't decode with vlc, ffmpeg, or tsreport. All messages indicate it can't find the codec in the stream which would explain why it can't decode the packets. I've double-checked the local channel frequency (on HDTV ch 34 with a center freq of 593 MHz). The raw signal looks good as does the waterfall for an ATSC signal. I've tried capturing with and without the initial low-pass filter in the attached flowgraph, I've tried using a HackRF at 6.2 MSPS instead of the Airspy at 10 MSPS, tried a true HDTV antenna (although it's 75 Ohm), and horizontal and vertical polarizations on the standard SDR antenna to get the cleanest frequency plot with the best visual SNR. I get there can be some bad packets in any data stream, but for the life of me I can't figure out if there's no errors coming from the decoder and it's decoding successfullly (i.e. producing data with no warnings) why the stream isn't readable. Anyone have any suggestions? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC won't work with SDRPlay
In case there are any other folks trying the ATSC receiver. I did some testing here, and any DC offset spike in the receiver will kill the ATSC demodulator. I'm not sure a DC block will work, but manually compensating the DC offset on a bladeRF did work. I guess offset tuning would also work, but it's a 6 MHz wide signal, so you need a pretty large offset. Ron On 09/04/2015 01:15 PM, Henry Barton wrote: Hi all. I've been trying to get the ATSC pipeline to work with 8MHz RF spectrum recordings from the SDRPlay. When I provide a 16-bit RAW IQ recording from HDSDR, centered on the TV channel, the script runs at 100% CPU for a long time and closes but the output TS file stays at 0 bytes. Any advice? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC blocks
I believe ATSC Field Sync Demux is now called ATSC Field Sync Checker. Ron On 09/03/2015 06:46 AM, Henry Barton wrote: I've got more info on my problem. Some of the blocks, including ATSC Field Sync Demux, are missing. Could they have been renamed or combined into other blocks? I don't understand why blocks would be missing from the latest stable Live DVD. Any light shed on this would be greatly appreciated. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoder example in GR 3.7.1
On Tue, Oct 15, 2013 at 10:01 PM, Ethan Trewhitt gnura...@potophobia.net wrote: As a part of my quest to understand some of the examples in GR (and eventually contribute some well-commented GRC examples of my own), I've been messing around with the atsc_rx.py script. Unfortunately, since I have a USRP2, I can't sample at 6.4Msps like the script wants. Instead, I tried sampling a strong local TV station at 10Msps and resampling at 6.4Msps, but the result is a ton of errors in the script's output and a large TS file that I can't make sense of. Hi Ethan, I just wanted to point out that we've been working with Andrew Davis on fixing up ATSC to a) work better and b) work with 3.7. He's made a good start on things here: https://github.com/glneo/gnuradio/tree/atscfixup There's still work to be done, and Johnathan and I have been talking about how to best get this into GNU Radio. If you're pursuing this project, definitely look here and maybe talk directly with Andrew. He's apparently gotten pretty busy with school work this semester, so having another person working on this might be really good to finish it up. Thanks, Tom I tried the following steps. First, capture a few seconds of raw TV signal (channel 39 in my area is the physical frequency of WSB): uhd_rx_cfile -f 623M --samp-rate=10M -s wsb.iq In a local copy of atsc_rx.py, I added the following filter: resamp = filter.fractional_resampler_cc(0, 10/6.4) Then I added the resampler to the graph at the bottom of the script: tb.connect( srcf, is2c, resamp, rrc, ilp, duc, c2f, fpll, lp_filter) Finally I ran the script: ./atsc_rx.py wsb.iq wsb.ts The console fills with errors related to the ATSC stream: 8404 Using Volk machine: avx_64_mmx_orc Setting initial_freq: 3065000.00 atsc_field_sync_demux: synced (FIELD-1) at 426209 [delta = 426209] atsc_viterbi_decoder: new starting offset = 0 atsc_field_sync_demux: lost sync at 464481 !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow atsc_viterbi_decoder: new starting offset = 7 !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow atsc_field_sync_demux: lost sync at 1225761 atsc_viterbi_decoder: new starting offset = 1... (and so on, many times over) I tried playing the output TS in vlc and reading it with avconv, but both programs found tons of errors with the file and couldn't do anything useful with it. For the record, with some tweaking of the Tx settings, I was able to transmit the captured IQ file over the air and play the clip on a nearby TV (on a different, unused channel), so I know the data is in there somewhere. My eventual goal is to turn this script into a GRC version, complete with GRC xml files for the ATSC blocks currently included in GR. However, I can't begin this process without having it working in the first place. Is there anyone out there who understands the current script and can modify it to work with an adjustable input sample rate? That would go a long way toward helping me understand it all. Thanks in advance. Ethan T (courtarro) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
Yeah, That doesn't seem to be anything I messed with, anyway I pushed another commit that if compiles for everyone could be merged into the Gnuradio master. I found that the Magic coupling constant isn't so magic and can be complexly removed and replaced with an AGC block set to a reference level of 4 ( the mean value of the pseudo-random 1 3 5 7 levels of the ATSC PAM signal ). So I separated that out of the fpll block. For some reason I simply cannot make a complex PLL that works the same way the old PLL works, I get close but i'm still missing something, once I get that figured out it will shave off approximately 12% from the decoding time ( thanks to the new performance counters I can now easily track what my fix-ups are doing and whats left before real-time decoding ). Thanks you, Andrew On Wed, Aug 7, 2013 at 4:11 PM, Souryal, Michael michael.sour...@nist.govwrote: I tried building this later push and this is as far as I got. ** ** [ 70%] Building CXX object gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o /raid/souryal/gnuradio-atscfixup/gr-qtgui/lib/TimeDomainDisplayPlot.cc: In member function ‘void TimeDomainDisplayPlot::setSemilogy(bool)’: /raid/souryal/gnuradio-atscfixup/gr-qtgui/lib/TimeDomainDisplayPlot.cc:358: error: ‘class QwtScaleDiv’ has no member named ‘upperBound’ make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o] Error 1 make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2 make: *** [all] Error 2 ** ** It doesn’t look related to ATSC, though. ** ** *From:* discuss-gnuradio-bounces+souryal=nist@gnu.org [mailto: discuss-gnuradio-bounces+souryal=nist@gnu.org] *On Behalf Of *Andrew Davis *Sent:* Monday, August 05, 2013 3:37 PM *To:* M. Ranganathan *Cc:* GNURadio Discussion List *Subject:* Re: [Discuss-gnuradio] ATSC fixups ** ** OK, pushed, could you see if that works better? ** ** Thank you Andrew ** ** On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis glneolistm...@gmail.com wrote: It was removed and left in fpll.h, i'll push a fix in just a bit, in the meantime you could just remove the include line from fpll.h ** ** Thank you Andrew ** ** On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan mra...@gmail.com wrote:** ** Hello, I git cloned the atscfixup branch and tried building it. Here's as far as I got: In file included from /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27: /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44: error: gnuradio/atsc/diag_output_impl.h: No such file or directory Perhaps this file was accidentally left out of the repository (?) Ranga ** ** On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/15/2013 07:01 PM, Andrew Davis wrote: After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. First, let me say that I'm very happy this code is getting some attention. It was originally written to use the low-IF output of a TV tuner and ADC, and also when GNU Radio only had a single-threaded scheduler. Later, it was only minimally modified to use the USRP complex baseband IQ output. (I wasn't around GNU Radio at the time and the above is only what I surmise by looking at the code history.) The changes you describe are more like it would have been written had the USRP existed at the time. The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I merged in, but he and I never finished what we were going to do with it.** ** Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. Agree. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! The upconversion and filtering is a large CPU waste when it could be done at baseband, but it seems this was just a quick-and-dirty way to get the baseband IQ from a USRP to look like a low-IF output instead in order to re-use what was already written and working. Real-time execution would be a welcome accomplishment! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. No need. By the way, before any of this can be merged, we'll need a copyright assignment from you. I'll email you off-list about how this works. Thanks again for working on this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services
Re: [Discuss-gnuradio] ATSC fixups
Hello, I git cloned the atscfixup branch and tried building it. Here's as far as I got: In file included from /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27: /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44: error: gnuradio/atsc/diag_output_impl.h: No such file or directory Perhaps this file was accidentally left out of the repository (?) Ranga On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/15/2013 07:01 PM, Andrew Davis wrote: After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. First, let me say that I'm very happy this code is getting some attention. It was originally written to use the low-IF output of a TV tuner and ADC, and also when GNU Radio only had a single-threaded scheduler. Later, it was only minimally modified to use the USRP complex baseband IQ output. (I wasn't around GNU Radio at the time and the above is only what I surmise by looking at the code history.) The changes you describe are more like it would have been written had the USRP existed at the time. The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I merged in, but he and I never finished what we were going to do with it. Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. Agree. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! The upconversion and filtering is a large CPU waste when it could be done at baseband, but it seems this was just a quick-and-dirty way to get the baseband IQ from a USRP to look like a low-IF output instead in order to re-use what was already written and working. Real-time execution would be a welcome accomplishment! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. No need. By the way, before any of this can be merged, we'll need a copyright assignment from you. I'll email you off-list about how this works. Thanks again for working on this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
It was removed and left in fpll.h, i'll push a fix in just a bit, in the meantime you could just remove the include line from fpll.h Thank you Andrew On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan mra...@gmail.com wrote: Hello, I git cloned the atscfixup branch and tried building it. Here's as far as I got: In file included from /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27: /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44: error: gnuradio/atsc/diag_output_impl.h: No such file or directory Perhaps this file was accidentally left out of the repository (?) Ranga On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/15/2013 07:01 PM, Andrew Davis wrote: After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. First, let me say that I'm very happy this code is getting some attention. It was originally written to use the low-IF output of a TV tuner and ADC, and also when GNU Radio only had a single-threaded scheduler. Later, it was only minimally modified to use the USRP complex baseband IQ output. (I wasn't around GNU Radio at the time and the above is only what I surmise by looking at the code history.) The changes you describe are more like it would have been written had the USRP existed at the time. The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I merged in, but he and I never finished what we were going to do with it. Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. Agree. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! The upconversion and filtering is a large CPU waste when it could be done at baseband, but it seems this was just a quick-and-dirty way to get the baseband IQ from a USRP to look like a low-IF output instead in order to re-use what was already written and working. Real-time execution would be a welcome accomplishment! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. No need. By the way, before any of this can be merged, we'll need a copyright assignment from you. I'll email you off-list about how this works. Thanks again for working on this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
OK, pushed, could you see if that works better? Thank you Andrew On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis glneolistm...@gmail.comwrote: It was removed and left in fpll.h, i'll push a fix in just a bit, in the meantime you could just remove the include line from fpll.h Thank you Andrew On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan mra...@gmail.com wrote: Hello, I git cloned the atscfixup branch and tried building it. Here's as far as I got: In file included from /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27: /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44: error: gnuradio/atsc/diag_output_impl.h: No such file or directory Perhaps this file was accidentally left out of the repository (?) Ranga On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/15/2013 07:01 PM, Andrew Davis wrote: After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. First, let me say that I'm very happy this code is getting some attention. It was originally written to use the low-IF output of a TV tuner and ADC, and also when GNU Radio only had a single-threaded scheduler. Later, it was only minimally modified to use the USRP complex baseband IQ output. (I wasn't around GNU Radio at the time and the above is only what I surmise by looking at the code history.) The changes you describe are more like it would have been written had the USRP existed at the time. The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I merged in, but he and I never finished what we were going to do with it. Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. Agree. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! The upconversion and filtering is a large CPU waste when it could be done at baseband, but it seems this was just a quick-and-dirty way to get the baseband IQ from a USRP to look like a low-IF output instead in order to re-use what was already written and working. Real-time execution would be a welcome accomplishment! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. No need. By the way, before any of this can be merged, we'll need a copyright assignment from you. I'll email you off-list about how this works. Thanks again for working on this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC Magic coupling constant
Hello All, Just an update for those following along, I have ( somewhat ) finished the ATSC transmitter, most of the blocks needed were all ready made, but they stopped right before pilot insertion and VSB modulation ( my guess is since the hardware back then was receive only they stopped there ), so I added the needed blocks, and transmitted with my USRP1 to a television. It is much faster than real time and so i'm trying to encode and transmit my webcam live but i'm still working on getting gstreamer to output the correct stream :) Also the receiver is coming along but i'm still stuck with the magic constant. I have a nice sample data recording from my USRP of my local TV station, it is just above the threshold for decent recovery and so should be good for testing improvements the the receiver. Would anyone like this sample for testing? Thank you all Andrew On Wed, Jul 31, 2013 at 5:00 PM, Andrew Davis glneolistm...@gmail.comwrote: Ok, I tried the off by sqrt(2) and it put me close but now the bit_timing _loop is running short on data again, which as a disseminator means it probably cant find a good sync for timing and just eats all its input samples. So I pushed my changes to where i'm at now to github, could you see if that compiles for you, then I could walk you though whats all going on with this and where i'm at. Thank you Andrew On Tue, Jul 30, 2013 at 8:12 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 07/30/2013 04:28 PM, Andrew Davis wrote: Thanks for the idea, I will try it tomorrow when I get back to the test machine ( which is powerful enough to be within reach of real-time decoding if I get this figured out :) If you don't get this straightened out, I'd be happy to work with you by phone or chat. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC Magic coupling constant
Ok, I tried the off by sqrt(2) and it put me close but now the bit_timing _loop is running short on data again, which as a disseminator means it probably cant find a good sync for timing and just eats all its input samples. So I pushed my changes to where i'm at now to github, could you see if that compiles for you, then I could walk you though whats all going on with this and where i'm at. Thank you Andrew On Tue, Jul 30, 2013 at 8:12 PM, Johnathan Corgan johnat...@corganlabs.comwrote: On 07/30/2013 04:28 PM, Andrew Davis wrote: Thanks for the idea, I will try it tomorrow when I get back to the test machine ( which is powerful enough to be within reach of real-time decoding if I get this figured out :) If you don't get this straightened out, I'd be happy to work with you by phone or chat. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC Magic coupling constant
On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis glneolistm...@gmail.comwrote: Hello all, I'm working on fixing up gr-atsc and I have been working on a little problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST ) that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is literally defined as Magic, so it seems to be a value that just works. With that value the AGC filters the real input and then this is multiplied by a NCO part of a PLL. This puts the value of the +/- 5 timing sync levels at about +/- 5. The problem is when I pass samples though the AGC and then do 'complex' multiplication on them the +/- 5 values end up at about +/- 7. I'm not sure why but it seems like the values coming out of the complex multiply are not the same as the real multiply. The original code is: nco.sincos (a_sin, a_cos); // compute cos and sin float I = input * a_sin; float Q = input * a_cos; My code is: nco.sincos (a_sin, a_cos); // compute cos and sin gr_complex result = (gr_complex(input_real, input_imag) * gr_complex(a_cos, a_sin)); float I = result.real(); float Q = result.imag(); I is larger in my version and so the equalizer and slicer fail downstream. I built a coherent AGC into the sync timing loop but it still fails with large gain differences. My question is whether there is anyone around who worked on gr-atsc who could give me a hint as to how the Magic coupling constant was derived in the first place so I can build a new one so I don't have to rebuild the equilizer. I can't help you with your MAGIC, but if you say the real signal is mixed then filtered in the original code that works, whereas it is just mixed with your code - maybe it's just off by a sqrt(2) since you're filtering off your image after the NCO happens and losing 1/2 power? I did notice that sqrt(2)*5 = 7 - so maybe making your NCO a little less powerful might bring you to the correct power levels since I am assuming you aren't filtering in your chain since there is no image to filter out? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC Magic coupling constant
The filter doesn't seem to decrease the pass-band signal, also I've tried adding back the unneeded filter just to be sure and it doesn't change anything. I will try the off by sqrt(2), that might put me back in range. Also my NCO is the same in both cases and I believe it is normalized to 1. The ATSC signal randomly changes between +/- 1,3,5,7 so the average power should be 4 and when using this as the reference this puts my signal were it should be and at the same level as the old code with the average power set to 7.8125 ( written in code as 2.5 * 3.125 for some reason ) yet it still must be off by just enough to mess up the slicer in the viterbi but not the equalizer as it locks on correctly ( it is very finicky ). Thanks for the idea, I will try it tomorrow when I get back to the test machine ( which is powerful enough to be within reach of real-time decoding if I get this figured out :) Andrew On Tue, Jul 30, 2013 at 6:19 PM, Brian Padalino bpadal...@gmail.com wrote: On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis glneolistm...@gmail.comwrote: Hello all, I'm working on fixing up gr-atsc and I have been working on a little problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST ) that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is literally defined as Magic, so it seems to be a value that just works. With that value the AGC filters the real input and then this is multiplied by a NCO part of a PLL. This puts the value of the +/- 5 timing sync levels at about +/- 5. The problem is when I pass samples though the AGC and then do 'complex' multiplication on them the +/- 5 values end up at about +/- 7. I'm not sure why but it seems like the values coming out of the complex multiply are not the same as the real multiply. The original code is: nco.sincos (a_sin, a_cos); // compute cos and sin float I = input * a_sin; float Q = input * a_cos; My code is: nco.sincos (a_sin, a_cos); // compute cos and sin gr_complex result = (gr_complex(input_real, input_imag) * gr_complex(a_cos, a_sin)); float I = result.real(); float Q = result.imag(); I is larger in my version and so the equalizer and slicer fail downstream. I built a coherent AGC into the sync timing loop but it still fails with large gain differences. My question is whether there is anyone around who worked on gr-atsc who could give me a hint as to how the Magic coupling constant was derived in the first place so I can build a new one so I don't have to rebuild the equilizer. I can't help you with your MAGIC, but if you say the real signal is mixed then filtered in the original code that works, whereas it is just mixed with your code - maybe it's just off by a sqrt(2) since you're filtering off your image after the NCO happens and losing 1/2 power? I did notice that sqrt(2)*5 = 7 - so maybe making your NCO a little less powerful might bring you to the correct power levels since I am assuming you aren't filtering in your chain since there is no image to filter out? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC Magic coupling constant
On 07/30/2013 04:28 PM, Andrew Davis wrote: Thanks for the idea, I will try it tomorrow when I get back to the test machine ( which is powerful enough to be within reach of real-time decoding if I get this figured out :) If you don't get this straightened out, I'd be happy to work with you by phone or chat. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis glneolistm...@gmail.comwrote: I have been working on getting gr-atsc running again, I have found a few speedups and some bugs that prevented ATSC decoding from working with new versions of GNURadio. I have put these fixes into a branch that can now decode signals from my local TV station. The changes are in commit in this branch: https://github.com/glneo/gnuradio/tree/atscfixup Andrew, can you detail the difference in implementation between the atsc_rx.py file you added and the all_atsc.py file that was there already? -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
Sure: - first the description is correct and not just copied from interp_short.py - removed the writing to 'atsc_complex.data' as this uses a lot of space and seems to have no meaning outside of debugging - I use interleave_short_to_complex instead of s2s - s2f - f2c chain - lp_coeffs and duc_coeffs uses input_rate instead of just the number, should make changing it easier - lp_coeffs no longer arbitrarily adds 3 gain - duc now shifts the frequency in the correct direction - the root raised cosine filter taps no longer need to be heterodyned into place as I just use it at baseband - the root raised cosine filer gets used now ( for some reason it was not in the chain before and this was severely causing ISI ) - lower_edge and upper_edge seemed arbitrary and were not in the right spot anyway After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. Thank you Andrew On Mon, Jul 15, 2013 at 6:52 PM, Johnathan Corgan johnat...@corganlabs.comwrote: On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis glneolistm...@gmail.comwrote: I have been working on getting gr-atsc running again, I have found a few speedups and some bugs that prevented ATSC decoding from working with new versions of GNURadio. I have put these fixes into a branch that can now decode signals from my local TV station. The changes are in commit in this branch: https://github.com/glneo/gnuradio/tree/atscfixup Andrew, can you detail the difference in implementation between the atsc_rx.py file you added and the all_atsc.py file that was there already? -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC fixups
On 07/15/2013 07:01 PM, Andrew Davis wrote: After this stuff and the reorganization a simple diff would not have saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence the name change. First, let me say that I'm very happy this code is getting some attention. It was originally written to use the low-IF output of a TV tuner and ADC, and also when GNU Radio only had a single-threaded scheduler. Later, it was only minimally modified to use the USRP complex baseband IQ output. (I wasn't around GNU Radio at the time and the above is only what I surmise by looking at the code history.) The changes you describe are more like it would have been written had the USRP existed at the time. The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I merged in, but he and I never finished what we were going to do with it. Also the other scripts seem unnecessary with the new thread-per-block sceduler, the also seem to cause a lot of beginners confusion. So I felt they needed to go. Agree. I have also built a ( semi ) working complex fpll for gr-atsc, this removes the need for up-converting and the filtering after the current fpll, my next atsc_rx will need the new script style. After I finish updating the bit timing loop we will be almost real time I believe! The upconversion and filtering is a large CPU waste when it could be done at baseband, but it seems this was just a quick-and-dirty way to get the baseband IQ from a USRP to look like a low-IF output instead in order to re-use what was already written and working. Real-time execution would be a welcome accomplishment! P.S. I could still just do the diff to the old all_atsc.py and rename if you want. No need. By the way, before any of this can be merged, we'll need a copyright assignment from you. I'll email you off-list about how this works. Thanks again for working on this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working
I've uploaded a sample of ATSC signal here: http://dl.dropbox.com/u/63648777/atsc_data_6m4_short.bz2 The format is interleaved shorts at 6.4 MS like the current ATSC code uses. I successfully decoded this data with gnuradio, so the receiver code does work. Here's how I see the signal flow through the first part of the receiver: input from usrp or file (6.4MS complex short) filter and translate (19.2MS real float) fpll (19.2MS real float) bit_timing_loop (~10.76MS real float) [+ other data?] field sync recovery James ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
Was anyone able to collect some ATSC data over the weekend? Also bump about my question about which fr.atsc module does the symbol detection and recovery. Thanks! shea_watson wrote: Alright. If I get it working I will post my fixes. Which part is not working? Also, my research only deals with extracting the bit delay to the data sync frame. So, I will not really be doing much with atsc decoding past getting a bit stream what would include the sync frame. Which also brings up another question. In the general signal flow of decoding the atsc with gnuradio, when will the data sync frame be uncovered? At the moment, I run interp_short, xlate, and fpll. Those translate the signal to baseband and I think fpll demodulates. Do any of you guys happen to know what fpll actually outputs? Like what form is the data in? Because I don't have real over the air data to run through this I can't crack it open to make sense of it. Is it raw binary bit stream after that stage? Again, my intuition is that fpll outputs the raw bitstream and to find the data sync frame I will be able to just run a binary correlator with the pn_511 sequence. Any advice would be helpful. Thanks! Johnathan Corgan-2 wrote: On Fri, Feb 17, 2012 at 08:31, Tom Rondeau t...@trondeau.com wrote: Also, we might be able to host some data files on gnuradio.org. I need to look into how much space we have or can set aside for this, but it would be nice to have stuff like this easily accessible. We can easily conjure up an extra 10 or 20 GB for an example data file volume. That's something like a dollar a month. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p33359750.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
Alright. If I get it working I will post my fixes. Which part is not working? Also, my research only deals with extracting the bit delay to the data sync frame. So, I will not really be doing much with atsc decoding past getting a bit stream what would include the sync frame. Which also brings up another question. In the general signal flow of decoding the atsc with gnuradio, when will the data sync frame be uncovered? At the moment, I run interp_short, xlate, and fpll. Those translate the signal to baseband and I think fpll demodulates. Do any of you guys happen to know what fpll actually outputs? Like what form is the data in? Because I don't have real over the air data to run through this I can't crack it open to make sense of it. Is it raw binary bit stream after that stage? Again, my intuition is that fpll outputs the raw bitstream and to find the data sync frame I will be able to just run a binary correlator with the pn_511 sequence. Any advice would be helpful. Thanks! Johnathan Corgan-2 wrote: On Fri, Feb 17, 2012 at 08:31, Tom Rondeau t...@trondeau.com wrote: Also, we might be able to host some data files on gnuradio.org. I need to look into how much space we have or can set aside for this, but it would be nice to have stuff like this easily accessible. We can easily conjure up an extra 10 or 20 GB for an example data file volume. That's something like a dollar a month. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p33348912.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
On Thu, Feb 16, 2012 at 4:43 PM, Nick Foster n...@ettus.com wrote: No, I don't know where that is... I can always take more data though. I'll post it on a Dropbox tonight or this weekend. I'm pretty sure the Gnuradio ATSC decoder is suffering from some massive bitrot though. If you do get it working for you, *please* post your changes for inclusion into Gnuradio! --n To echo Nick, PLEASE submit your fixes if you get this working again. It's been on my todo list for a long time, but I just never get a chance to work on it. Would be great to get it back into shape again. Also, we might be able to host some data files on gnuradio.org. I need to look into how much space we have or can set aside for this, but it would be nice to have stuff like this easily accessible. Tom On Thu, Feb 16, 2012 at 1:31 PM, shea_watson watson.s...@gmail.comwrote: Nick, I apologize if this is bringing back old ghosts but I am doing research with ATSC signals and gnuradio and would like that sample ATSC capture that you posted. i cannot find where you posted it. Do you happen to still have it? Thanks, SW Nick Foster-4 wrote: Achilleas, I live all of a half mile away from the local 10MW broadcast tower, so I can almost hear ATSC in my fillings at night. I'll get an ATSC capture and post it online tonight. --n On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote: Bryce and others, is there any way someone can post captured sample atsc files for downloading and testing. I have some ideas for improving the atsc implementation but need to test some things before i propose something meaningful... Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
On Fri, Feb 17, 2012 at 08:31, Tom Rondeau t...@trondeau.com wrote: Also, we might be able to host some data files on gnuradio.org. I need to look into how much space we have or can set aside for this, but it would be nice to have stuff like this easily accessible. We can easily conjure up an extra 10 or 20 GB for an example data file volume. That's something like a dollar a month. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
Nick, I apologize if this is bringing back old ghosts but I am doing research with ATSC signals and gnuradio and would like that sample ATSC capture that you posted. i cannot find where you posted it. Do you happen to still have it? Thanks, SW Nick Foster-4 wrote: Achilleas, I live all of a half mile away from the local 10MW broadcast tower, so I can almost hear ATSC in my fillings at night. I'll get an ATSC capture and post it online tonight. --n On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote: Bryce and others, is there any way someone can post captured sample atsc files for downloading and testing. I have some ideas for improving the atsc implementation but need to test some things before i propose something meaningful... Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
No, I don't know where that is... I can always take more data though. I'll post it on a Dropbox tonight or this weekend. I'm pretty sure the Gnuradio ATSC decoder is suffering from some massive bitrot though. If you do get it working for you, *please* post your changes for inclusion into Gnuradio! --n On Thu, Feb 16, 2012 at 1:31 PM, shea_watson watson.s...@gmail.com wrote: Nick, I apologize if this is bringing back old ghosts but I am doing research with ATSC signals and gnuradio and would like that sample ATSC capture that you posted. i cannot find where you posted it. Do you happen to still have it? Thanks, SW Nick Foster-4 wrote: Achilleas, I live all of a half mile away from the local 10MW broadcast tower, so I can almost hear ATSC in my fillings at night. I'll get an ATSC capture and post it online tonight. --n On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote: Bryce and others, is there any way someone can post captured sample atsc files for downloading and testing. I have some ideas for improving the atsc implementation but need to test some things before i propose something meaningful... Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Zero Output Problem - Update
Hi all, I did some investigations regarding the zero output problem: First of all I installed gnuradio 0.9 on an old Red Hat 9 installation and made tests with the files from http://comsec.com/data/README. As the 0.9 ATSC DTV decoder works fine, I took the intermediate save files (*.rxout, can be obtained when using the log function) and used them as input for the version 3.x ATSC decoder. It turned out that everything works fine if I use the 0.9 output after the bit timing loop (bt_*.rxout) as input for the 3.x frame sync block. Further, if I use the 0.9 fpll output as input for the 3.x bit timing loop nothing happens (zero output). So I guess the problem can be isolated to the bit timing loop. I still do not fully understand the code, so I hope someone can help me to further isolate the problem. If we can fix this we would finally have a working gnuradio ATSC receiver again! Regards Klaus -Ursprüngliche Nachricht- Von: discuss-gnuradio-bounces+klaus.hueske=tu-dortmund...@gnu.org [mailto:discuss-gnuradio-bounces+klaus.hueske=tu-dortmund...@gnu.org] Im Auftrag von Klaus Hueske Gesendet: Donnerstag, 24. Juni 2010 09:52 An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] ATSC decoding Hi Stephen, Did you make progress with this zero byte output problem? Anyway, I'm wondering if the ATSC receiver implementation will work at all with the current version of Gnuradio. It looks like parts of the original ATSC implementation that was working with Gnuradio 0.9 have been adapted to be used in Gnuradio 2.0, but now we have 3.2.2. Anyone here who can verify that the provided code can decode ATSC signals? Thanks Klaus --- On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch addr...@hidden wrote: Hello everyone, I am part of Auburn University's Software Defined Radio Senior Design team, Software being used: Ubuntu v.9.10 on xfs partition GNURadio v.3.3 (git) Xine Available hardware: USRP1, USRP2, WBX daughterboard, TVRX daughterboard We followed the instructions in ./gnuradio/gr-atsc/src/python/README to no success. Using the FFT we found 507.25M to have a strong signal. According to http://en.wikipedia.org/wiki/North_American_broadcast_television_freque ncie s#UHF_band this is channel 20. And according to http://www.fcc.gov/fcc-bin/tvq?state=ALcall=arn=city=chan=14cha2=6 9se rv=type=0facid=list=2dist=dlat2=mlat2=slat2=dlon2=mlon2=slon2= siz e=9 this is WCOV from Montgomery, Alabama. So we do have the correct video carrier frequency, which I assume is the frequency we want to record and decode into a video. Question #1) Is the video carrier the one that carriers the video, or would it be the ATSC carrier? We then used: ./usrp_rx_cfile.py -s -d 10 -g 20 -f 507.25e6 atsc_data_6-4m_complex ./interp_short.py atsc_data_6-4m_complex ./xlate.py ./fpll.py ./btl-fsd.py ./viterbi-out.py test.mpeg Problems: /tmp/atsc_pipe_5 never fills with data. The output file, 'test.mpeg' is empty. Question #2) What do we need to fix to get /tmp/atsc_pipe_5 to fill. Question #3) What do we need to fix to get temp.mpeg to fill. Thank you, Bobby Black Stephen Branch addr...@hidden (please do not blank out this email) black85 @ auburn . edu Bobby Black Auburn University addr...@hidden (334) 804-4826 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding
Hi Stephen, Did you make progress with this zero byte output problem? Anyway, I'm wondering if the ATSC receiver implementation will work at all with the current version of Gnuradio. It looks like parts of the original ATSC implementation that was working with Gnuradio 0.9 have been adapted to be used in Gnuradio 2.0, but now we have 3.2.2. Anyone here who can verify that the provided code can decode ATSC signals? Thanks Klaus --- On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch addr...@hidden wrote: Hello everyone, I am part of Auburn University's Software Defined Radio Senior Design team, Software being used: Ubuntu v.9.10 on xfs partition GNURadio v.3.3 (git) Xine Available hardware: USRP1, USRP2, WBX daughterboard, TVRX daughterboard We followed the instructions in ./gnuradio/gr-atsc/src/python/README to no success. Using the FFT we found 507.25M to have a strong signal. According to http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencie s#UHF_band this is channel 20. And according to http://www.fcc.gov/fcc-bin/tvq?state=ALcall=arn=city=chan=14cha2=69se rv=type=0facid=list=2dist=dlat2=mlat2=slat2=dlon2=mlon2=slon2=siz e=9 this is WCOV from Montgomery, Alabama. So we do have the correct video carrier frequency, which I assume is the frequency we want to record and decode into a video. Question #1) Is the video carrier the one that carriers the video, or would it be the ATSC carrier? We then used: ./usrp_rx_cfile.py -s -d 10 -g 20 -f 507.25e6 atsc_data_6-4m_complex ./interp_short.py atsc_data_6-4m_complex ./xlate.py ./fpll.py ./btl-fsd.py ./viterbi-out.py test.mpeg Problems: /tmp/atsc_pipe_5 never fills with data. The output file, 'test.mpeg' is empty. Question #2) What do we need to fix to get /tmp/atsc_pipe_5 to fill. Question #3) What do we need to fix to get temp.mpeg to fill. Thank you, Bobby Black Stephen Branch addr...@hidden (please do not blank out this email) black85 @ auburn . edu Bobby Black Auburn University addr...@hidden (334) 804-4826 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding
Tom Rondeau trondeau1...@gmail.com 04/20/10 9:58 AM On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch bran...@auburn.edu wrote: Hello everyone, I am part of Auburn University's Software Defined Radio Senior Design team, Software being used: Ubuntu v.9.10 on xfs partition GNURadio v.3.3 (git) Xine Available hardware: USRP1, USRP2, WBX daughterboard, TVRX daughterboard We followed the instructions in ./gnuradio/gr-atsc/src/python/README to no success. Using the FFT we found 507.25M to have a strong signal. According to http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies#UHF_band this is channel 20. And according to http://www.fcc.gov/fcc-bin/tvq?state=ALcall=arn=city=chan=14cha2=69serv=type=0facid=list=2dist=dlat2=mlat2=slat2=dlon2=mlon2=slon2=size=9 this is WCOV from Montgomery, Alabama. So we do have the correct video carrier frequency, which I assume is the frequency we want to record and decode into a video. Question #1) Is the video carrier the one that carriers the video, or would it be the ATSC carrier? If it's ATSC, you should see a very strong carrier with a very small lump of energy to the left of it (this is the vestigial sideband) and a large, fairly flat signal to the right that rolls off. This likely won't be flat due to fading, but you should be able to recognize it as a 6 MHz chunk of spectrum being occupied. You probably already know this, but I'm pointing it out to help distinguish between the ATSC carrier and video carrier. In NTSC, there were a few different carriers while in ATSC there's just the one big guy. And you want to use the ATSC carrier. This wikipedia article gives you the frequencies: http://en.wikipedia.org/wiki/Television_channel_frequencies#Americas_.28most_countries.29.2C_South_Korea.2C_Taiwan_and_the_Philippines For the channel you're looking at (20), the carrier would be at 507.31 MHz. There's a PLL to lock to the carrier, but I'm not sure if it's broad enough to handle the 60 kHz offset you're using. This could be the cause of your problem. In general, you should be able to output the different stages to files by editing the Python code and take a look at different stages to see what's going on. This might help identify where the problem is. Tom We then used: ./usrp_rx_cfile.py -s -d 10 -g 20 -f 507.25e6 atsc_data_6-4m_complex ./interp_short.py atsc_data_6-4m_complex ./xlate.py ./fpll.py ./btl-fsd.py ./viterbi-out.py test.mpeg Problems: /tmp/atsc_pipe_5 never fills with data. The output file, 'test.mpeg' is empty. Question #2) What do we need to fix to get /tmp/atsc_pipe_5 to fill. Question #3) What do we need to fix to get temp.mpeg to fill. Thank you, Bobby Black Stephen Branch Auburn University blac...@auburn.edu (334) 804-4826 Thanks Tom, Just for clarification: You said: For the channel you're looking at (20), the carrier would be at 507.31 MHz. There's a PLL to lock to the carrier, but I'm not sure if it's broad enough to handle the 60 kHz offset you're using. This could be the cause of your problem. What exactly do you mean by a 60kHz offset? We're not sure where we are using such an offset. Are there alternatives to how we're doing this that may yield better results? Thanks again, Auburn University Senior Design Team: Software Group Stephen Branch and Bobby Black bran...@auburn.edu blac...@auburn.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding
On Wed, Apr 21, 2010 at 3:48 PM, Stephen Branch bran...@auburn.edu wrote: Hi Tom, Thanks for the response. Just for clarification: You said: For the channel you're looking at (20), the carrier would be at 507.31 MHz. There's a PLL to lock to the carrier, but I'm not sure if it's broad enough to handle the 60 kHz offset you're using. This could be the cause of your problem. What exactly do you mean by a 60kHz offset? We're not sure where we are using such an offset. Are there alternatives to how we're doing this that may yield better results? You said you were looking for a carrier at 507.25 MHz. I said the carrier is at 507.31 MHz. That's a 60 kHz offset. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding
On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch bran...@auburn.edu wrote: Hello everyone, I am part of Auburn University's Software Defined Radio Senior Design team, Software being used: Ubuntu v.9.10 on xfs partition GNURadio v.3.3 (git) Xine Available hardware: USRP1, USRP2, WBX daughterboard, TVRX daughterboard We followed the instructions in ./gnuradio/gr-atsc/src/python/README to no success. Using the FFT we found 507.25M to have a strong signal. According to http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies#UHF_band this is channel 20. And according to http://www.fcc.gov/fcc-bin/tvq?state=ALcall=arn=city=chan=14cha2=69serv=type=0facid=list=2dist=dlat2=mlat2=slat2=dlon2=mlon2=slon2=size=9 this is WCOV from Montgomery, Alabama. So we do have the correct video carrier frequency, which I assume is the frequency we want to record and decode into a video. Question #1) Is the video carrier the one that carriers the video, or would it be the ATSC carrier? If it's ATSC, you should see a very strong carrier with a very small lump of energy to the left of it (this is the vestigial sideband) and a large, fairly flat signal to the right that rolls off. This likely won't be flat due to fading, but you should be able to recognize it as a 6 MHz chunk of spectrum being occupied. You probably already know this, but I'm pointing it out to help distinguish between the ATSC carrier and video carrier. In NTSC, there were a few different carriers while in ATSC there's just the one big guy. And you want to use the ATSC carrier. This wikipedia article gives you the frequencies: http://en.wikipedia.org/wiki/Television_channel_frequencies#Americas_.28most_countries.29.2C_South_Korea.2C_Taiwan_and_the_Philippines For the channel you're looking at (20), the carrier would be at 507.31 MHz. There's a PLL to lock to the carrier, but I'm not sure if it's broad enough to handle the 60 kHz offset you're using. This could be the cause of your problem. In general, you should be able to output the different stages to files by editing the Python code and take a look at different stages to see what's going on. This might help identify where the problem is. Tom We then used: ./usrp_rx_cfile.py -s -d 10 -g 20 -f 507.25e6 atsc_data_6-4m_complex ./interp_short.py atsc_data_6-4m_complex ./xlate.py ./fpll.py ./btl-fsd.py ./viterbi-out.py test.mpeg Problems: /tmp/atsc_pipe_5 never fills with data. The output file, 'test.mpeg' is empty. Question #2) What do we need to fix to get /tmp/atsc_pipe_5 to fill. Question #3) What do we need to fix to get temp.mpeg to fill. Thank you, Bobby Black Stephen Branch blac...@auburn.edu (please do not blank out this email) black85 @ auburn . edu Bobby Black Auburn University blac...@auburn.edu (334) 804-4826 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] ATSC demod tips
Wuest Brandon-WTVR47 wrote: I got a few underruns during the usrp_rx_cfile. About 10 in 10 seconds. The raw data file is 446 meg. Underruns are bad. Try capturing the data to a ram disk instead of your hard drive if you do not have a faster hard drive setup available (i.e. RAID). I used the ATSC demodulator a few months back and was never able to successfully store that data down to my hard drive, so I allocated a 512 MB ramdisk and used that which worked great. I am having the same issue. When using a ramdisk I get no usrp overruns but still the output file is empty. When putting the output of each py file in its own file, I found btl-fsd.py outputs nothing. Are there any obvious reasons why this would be happening? Is there anything I can do to narrow down the problem? -- View this message in context: http://www.nabble.com/ATSC-demod-tips-tp19446876p19611184.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC demod tips
On Mon, Sep 22, 2008 at 09:05:56AM -0700, Ben Green wrote: Wuest Brandon-WTVR47 wrote: I got a few underruns during the usrp_rx_cfile. About 10 in 10 seconds. The raw data file is 446 meg. Underruns are bad. Try capturing the data to a ram disk instead of your hard drive if you do not have a faster hard drive setup available (i.e. RAID). I used the ATSC demodulator a few months back and was never able to successfully store that data down to my hard drive, so I allocated a 512 MB ramdisk and used that which worked great. I am having the same issue. When using a ramdisk I get no usrp overruns but still the output file is empty. When putting the output of each py file in its own file, I found btl-fsd.py outputs nothing. Are there any obvious reasons why this would be happening? Is there anything I can do to narrow down the problem? If you are trying to capture continuous data, there is no substitute for a disk subsystem that can sustain the required throughput. In general we've had better luck using ext2 file systems rather than ext3 file systems. (You can mount an ext3 as an ext2.) Posting the ext3 journal was causing a problem last time I looked at this in detail ( 2 years ago). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC demod tips
Eric Blossom wrote: If you are trying to capture continuous data, there is no substitute for a disk subsystem that can sustain the required throughput. For capturing short segments (500 MB raw data) is a ram disk not sufficient? -- View this message in context: http://www.nabble.com/ATSC-demod-tips-tp19446876p19614781.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC demod tips
On Mon, Sep 22, 2008 at 12:23:20PM -0700, Ben Green wrote: Eric Blossom wrote: If you are trying to capture continuous data, there is no substitute for a disk subsystem that can sustain the required throughput. For capturing short segments (500 MB raw data) is a ram disk not sufficient? If that's enough for your purposes, then sure, it'll work. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] ATSC demod tips
I got a few underruns during the usrp_rx_cfile. About 10 in 10 seconds. The raw data file is 446 meg. Underruns are bad. Try capturing the data to a ram disk instead of your hard drive if you do not have a faster hard drive setup available (i.e. RAID). I used the ATSC demodulator a few months back and was never able to successfully store that data down to my hard drive, so I allocated a 512 MB ramdisk and used that which worked great. Thanks, Brandon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC
On 10/5/07, Meiners, Jason [EMAIL PROTECTED] wrote: Could someone send me a zipped file of the gr-atsc directory in trunk? I have had zero luck getting svc to work properly. http://gnuradio.org/trac/wiki/Download Please note the FTP links of the released code. Thanks for your help. No problem! Have fun! Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC
Here it is: www.nd.edu/~ematlis/z.gnuradio/gr-atsc.tar.gz eric Eric H. Matlis, Ph.D. Aerospace Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Fri, 5 Oct 2007, Meiners, Jason wrote: Could someone send me a zipped file of the gr-atsc directory in trunk? I have had zero luck getting svc to work properly. Thanks for your help. Jason [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC real-time application?
On Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote: I am quite interested in the ATSC project due to some previous HDTV RD experience. I am not quite sure about the current status of this project. According to my understanding, ATSC has a very high throughput requirement with a symbol rate=10.72M / sec Considering this high symbol rate and the computationally intense algorithm in RS decoder, Equalizer, Viterbi, etc., I am just wondering how powerful the computer has to be to process all these in realtime? What kind of computers have been used in the gr-atsc project to process realtime HDTV? None that I know of. With a 4-cpu 2Ghz system with the processes spread out so the total utilization is 80%, there's still a maybe (rough guess) 7:1 process-time to real-time ratio. At least I seem to remember taking at least 14 hours to process a 2 hour movie. The bottleneck (cpu running 99%) was still the gnuradio0.9 part from bit-timing-loop to field-sync-demux. Once atsc is completely ported to the 2.x framework more can be done to optimize things. Recalling that a PC do not have the luxury of parallel computation. For instance, a 4.0G CPU has to process one symbol in 400 clock durations, which seems to be not enough. That's the question - is the most intensive atsc function too much for a commonly available cpu to process in realtime? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] ATSC real-time application?
Has anyone benchmarked the ATSC encode function? Can this be done in real time? Decode is always harder to do than encode :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Swiger Sent: Friday, October 27, 2006 10:56 AM To: Kyle Zhou Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] ATSC real-time application? On Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote: I am quite interested in the ATSC project due to some previous HDTV RD experience. I am not quite sure about the current status of this project. According to my understanding, ATSC has a very high throughput requirement with a symbol rate=10.72M / sec Considering this high symbol rate and the computationally intense algorithm in RS decoder, Equalizer, Viterbi, etc., I am just wondering how powerful the computer has to be to process all these in realtime? What kind of computers have been used in the gr-atsc project to process realtime HDTV? None that I know of. With a 4-cpu 2Ghz system with the processes spread out so the total utilization is 80%, there's still a maybe (rough guess) 7:1 process-time to real-time ratio. At least I seem to remember taking at least 14 hours to process a 2 hour movie. The bottleneck (cpu running 99%) was still the gnuradio0.9 part from bit-timing-loop to field-sync-demux. Once atsc is completely ported to the 2.x framework more can be done to optimize things. Recalling that a PC do not have the luxury of parallel computation. For instance, a 4.0G CPU has to process one symbol in 400 clock durations, which seems to be not enough. That's the question - is the most intensive atsc function too much for a commonly available cpu to process in realtime? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] ATSC real-time application?
On Fri, 2006-10-27 at 11:11 -0500, Meiners, Jason wrote: Has anyone benchmarked the ATSC encode function? Can this be done in real time? Decode is always harder to do than encode :) Actually, an HDTV transmitter function might fulfill a niche that couldn't be easily implemented otherwise. A pchdtv HD-5500 is $130, but these can't be cheap: http://www.broadcast.harris.com/product_portfolio/product_details.asp?sku=WWWAPEX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] ATSC real-time application?
On Fri, 2006-10-27 at 19:47 -0400, Charles Swiger wrote: On Fri, 2006-10-27 at 11:11 -0500, Meiners, Jason wrote: Has anyone benchmarked the ATSC encode function? Can this be done in real time? Decode is always harder to do than encode :) Actually, an HDTV transmitter function might fulfill a niche that couldn't be easily implemented otherwise. A pchdtv HD-5500 is $130, but these can't be cheap: http://www.broadcast.harris.com/product_portfolio/product_details.asp?sku=WWWAPEX Actually it looks pretty good - the randomizer, Reed-Solomon encoder, interleaver and Trellis Encoder already work in 2.x, all we need to run in 0.9 is Field Sync Mux, Symbol Mapper and Weaver Mod head/tail - drive a basic-TX and suitable analog upconverter and you have a low power hi-def tv station ;) Will an RFX400 pass a 6MHz wide signal? (AD834X mixer) Here's the output of 0.9 atsc_tx re-sending some mpeg captured from a local station (via a disk file, not realtime yet): http://webpages.charter.net/cswiger/photos/atsc_tx_09.jpg ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC real-time application?
Will an RFX400 pass a 6MHz wide signal? (AD834X mixer) Easily Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc speed boost
On Wed, 2006-05-17 at 15:52 -0400, Charles Swiger wrote: just collect data with decim = 10, then interp by 3 (6.4Msps to 19.2Msps), then upshift. The 0.9 code need two changes, one to Some more fat can be squeezed out of the pipeline if the 'upshift to 5.75MHz' and FPLL could be combined. Both are in the gr2 realm, but as it is, the FPLL is just a 2.0 wrapper on the old code, which takes float in/out so the spectrum has to be all real positive frequencies. A complex version that can take a pilot freq of -2.69Mhz I think would help. It would also eliminate the need for a mixer image lp filter. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc signal plots
On Sat, May 06, 2006 at 10:16:15AM -0400, Chuck Swiger wrote: On Fri, 2006-05-05 at 14:45 -0700, Matt Ettus wrote: The 2.0 port isn't doing as well - a few eyes show up here and there: http://webpages.charter.net/cswiger/g2_eq_data-1.jpg Yep - looking at the 0.9 bit-timing-loop output: http://webpages.charter.net/cswiger/g09_btl_data-1.jpg vs a 2.x port of it shows something going wrong, using the same input data: http://webpages.charter.net/cswiger/g2_btl_data-1.jpg could be something to do with differences in buffering, scheduling, etc between gr0.9 and gr2.x. I think it's some kind of a porting error ;) Sorry, I can't get to it right now, but please ping me early next week if you haven't got it sorted out. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc signal plots
On Fri, 2006-05-05 at 14:45 -0700, Matt Ettus wrote: The 2.0 port isn't doing as well - a few eyes show up here and there: http://webpages.charter.net/cswiger/g2_eq_data-1.jpg and that's with the NOP equalizer. The LMS eq is all noise all the time. To me it looks like the symbol timing tracker is not tracking properly. As the sample time shifts relative to the correct sample time you come in and out of alignment. As I recall, the equalizer comes after the timing sync, so it won't work. It needs proper symbol timing, and without it will actually make things worse. Yep - looking at the 0.9 bit-timing-loop output: http://webpages.charter.net/cswiger/g09_btl_data-1.jpg vs a 2.x port of it shows something going wrong, using the same input data: http://webpages.charter.net/cswiger/g2_btl_data-1.jpg could be something to do with differences in buffering, scheduling, etc between gr0.9 and gr2.x. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc signal plots
The 2.0 port isn't doing as well - a few eyes show up here and there: http://webpages.charter.net/cswiger/g2_eq_data-1.jpg and that's with the NOP equalizer. The LMS eq is all noise all the time. To me it looks like the symbol timing tracker is not tracking properly. As the sample time shifts relative to the correct sample time you come in and out of alignment. As I recall, the equalizer comes after the timing sync, so it won't work. It needs proper symbol timing, and without it will actually make things worse. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc - field sync mux/demux questions
Well - the good news - plowing blindly ahead I shoveled
everything from GrAtscFieldSyncMux into a new
atsc_field_sync_mux and it actually compiles and might
be producing meaningful results. At least scrolling out
to segment 313 shows a segment full of 1's and 6's that
might match a pn511 reference symbol field.
However it's not so simple with demux - the old code has:
GrAtscFieldSyncDemux::work (VrSampleRange output, void *ao[],
VrSampleRange inputs[], void *ai[])
...
d_lost_index = inputs[0].index + ii;
But that won't compile in 2.0. Using something like:
atsc_field_sync_demux::work (int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const atsc_data_segment *in = (const atsc_data_segment *)
input_items[0];
...
d_lost_index = in[0].index + ii;
understandably gets:
atsc_field_sync_demux.cc: In member function `virtual int
atsc_field_sync_demux::work(int, gr_vector_const_void_star,
gr_vector_void_star)':
atsc_field_sync_demux.cc:79: error: 'const class atsc_data_segment' has
no member named 'index'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc receiver error rate: 5.19e-05
As a side note, if you want to keep the program in HD you can burn the MPEG program on a standard red-laser DVD and play them with this DVD player: http://pro.jvc.com/prof/attributes/press_res.jsp?model_id=MDL101546feature_id=08 You'll have to burn it as a DL disc, but 8 MB would fit. You can also encode it to WMV-HD or DiVX-HD to make the program much smaller. This is all kind of stop-gap until we get HD-DVD and/or Blu-Ray. But it is sweet to play HD content off a DVD. On Wed, 19 Apr 2006, Charles Swiger wrote: I thought this was pretty good for last night's recording of Boston Legal: end of file, exiting 661 errors out of 12727848 mpeg packets. 12727187 good packets. Error rate = 5.19e-05 That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna. What works so far is: recording an hour long program in 3 20-minute segments, making about 80Gb per segment. Then running gnuradio-0.9 on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about 10AM the next day they're done. Then concatenate the 3 transport streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, and out pops one hour long 720x480 ntsc high quality dvd, all from thin air. Tonight's target video: Bones. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc receiver error rate: 5.19e-05
On Wed, Apr 19, 2006 at 01:18:26PM -0400, Charles Swiger wrote: I thought this was pretty good for last night's recording of Boston Legal: end of file, exiting 661 errors out of 12727848 mpeg packets. 12727187 good packets. Error rate = 5.19e-05 That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna. What works so far is: recording an hour long program in 3 20-minute segments, making about 80Gb per segment. Then running gnuradio-0.9 on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about 10AM the next day they're done. Then concatenate the 3 transport streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, and out pops one hour long 720x480 ntsc high quality dvd, all from thin air. Tonight's target video: Bones. --Chuck Cool. It's too bad you have to downsample to 720x480 from 1920x1080 or whatever it was you started with. Maybe you need to install MythTV? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
