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 Date: Mon, Apr 24, 2017 at 7:12 AM Subject: Re: [Discuss-gnuradio] ATSC Decode Issues To: Ron Economos 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 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 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: >>
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
[Discuss-gnuradio] ATSC Decode Issues
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! hdtv_airspy_receiveV2.2.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC decode successful on SDRPlay RSP
Hi everyone. With help from Ron Economos, I managed to make ATSC decoding work using the SDRPlay RSP. The big issue was that the RSP has a DC bar in the middle of the waterfall. Canceling it in the SDR program isn't enough; you have to get the latest driver and use the EXTIO options *in addition* to the Automatic DC cancellation in HDSDR.___ 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
[Discuss-gnuradio] ATSC won't work with SDRPlay
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
[Discuss-gnuradio] ATSC blocks
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 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
[Discuss-gnuradio] ATSC decoder example in GR 3.7.1
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. 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
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 wrote: > 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 > 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 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 wa
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 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 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
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 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
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 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 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 wrote: > 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 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
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 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 wrote: > On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis wrote: > >> 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 Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis wrote: > 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
[Discuss-gnuradio] ATSC Magic coupling constant
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. Thank you Andrew Davis ___ 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 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 wrote: > On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote: > > >> 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 Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote: > 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
[Discuss-gnuradio] ATSC fixups
Hello all, 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 Thank you Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC Cleanups
Hello All, I've been recently playing with the ATSC decoding functions and have a couple questions. First the last time ATSC was discussed in any real detail was 4 years ago ( according to Google history of this mailing list ), and the converting of GR0.9 code to GR2.0 was raised, but in the repository all the functions look like they are 2.0, what still needs converted and why are all the files mirrored as the old versions ( GrAtscFPLL.cc and atsc_fpll.cc ) are the old versions still needed? Also the python code to put the blocks together seem dated, Is there any reason to use pipes and not just have all the code in one file and use IPC? ( also /tmp/atsc_pipe_4 is never used ) Thanks Andrew ___ 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 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 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 Fri, Feb 17, 2012 at 08:31, Tom Rondeau 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!
On Thu, Feb 16, 2012 at 4:43 PM, Nick Foster 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 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 > > ___ 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 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 - 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 - 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 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=AL&call=&arn=&city=&chan=14&cha2=6 9&se rv=&type=0&facid=&list=2&dist=&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 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=AL&call=&arn=&city=&chan=14&cha2=69&se rv=&type=0&facid=&list=2&dist=&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
On Wed, Apr 21, 2010 at 3:48 PM, Stephen Branch 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
>>> Tom Rondeau 04/20/10 9:58 AM >>> On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch 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=AL&call=&arn=&city=&chan=14&cha2=69&serv=&type=0&facid=&list=2&dist=&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 Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch 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=AL&call=&arn=&city=&chan=14&cha2=69&serv=&type=0&facid=&list=2&dist=&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
[Discuss-gnuradio] ATSC decoding
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=AL&call=&arn=&city=&chan=14&cha2=69&serv=&type=0&facid=&list=2&dist=&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? 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
[Discuss-gnuradio] ATSC receiving/demodulation/decoding
This is Auburn University's Software Defined Radio Senior Design Team, Our goals are to receive and output FM Radio (which we currently have working) and also to Receive, Decode, and Display HDTV through SDR. We have a USRP1, USRP2, a WBX and a TVRX card, using any combination of this hardware, what would be the best way to receive and decode atsc signals so we can watch hdtv? Some other questions we have: What is the current state of ATSC decoding to watch HDTV? How close to real time can be achieved with the USRP2? For the ATSC part of our project we have been adhering closely to the Readme File found in /gnuradio/gr-atsc/src/python. As far as the results after following the process mentioned in the Readme: Our problems are similar to those I have seen a few posts on the mailing list for already with no replies. The output file is empty. Pipe 5 never seems to get any data. And there is a taps.txt file created which is also empty. We have implemented the suggestions from previous posts to similar problems: We have verified the output of usrp_fft.py as I have seen mentioned. We have tried with latest distributions of LINUX and GNU Radio. - Ubuntu v.9.10 w/ reiserfs, and then after seeing a post on the mailing-list we switched to using xfs - GnuRadio v.3.2.2 - and the git on the bleeding edge of GnuRadio We have tried using both the USRP1 and the USRP2 but with the same problems. Thanks, Stephen Branch and Bobby Black bran...@auburn.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC Signal Receiving Output File Empty
Hi Everyone, I recently begin to use GNU Radio to receive ATSC signal. The GNU Radio version is the most updated Developer version on Ubuntu 9.04. I followed the steps of README in /gnuradio/gr-atsc/src/python/. I set the frequency to be 557M decimation to be 10 and number of samples to collected to be 200M. There is no overrun or under run during collecting the data. After excuting interp_short.py, xlable.py, fpll.py, btl-fsd.py and viterbi-out.py, the output file is empty. I set each of the py programs to output file, and saw that the output of btl-fsd.py is empty. There were someone posting a similar question on the disscussion list, but I didn't find the answer to that. Do you have any opinion about this? Is the parameters setting causing the problem or I am operating this incorrectly? Thanks a lot! Ying ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC decode
Hi all, I am new with GNUradio and USRP. I am using the atsc to decode hdtv but I have no luck.I get some sync errors from btl-fds.py >>> gr_fir_fff: using SSE atsc_field_sync_demux: synced (FIELD-1) at 426606 [delta = 426606] !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow !!! atsci_equalizer: expected field sync, didn't find one atsc_field_sync_demux: segment number overflow I get an output from the viterbi-out.py but I can not pla the output mpeg file with mplayer. Can you help me please with this situation. Thank you I use the readme from gnuradio/gr-atsc/src/python to decode ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc
I need a little help with atsc demodulation procedure, I used the procedure found in the README 1) Verify signal, adjust antenna and find best gain setting using usrp_fft.py, station frequency from the fcc video database, and decimation of 10. 2) Capture data - adjust gain (-g) frequency (-f) and which side the tvrx is on to fit your local setup: usrp_rx_cfile.py -s -R B -d 10 -g 65 -f 503e6 atsc_data_6-4m_complex---I did not use this command ./usrp2_rx_cfile.py -s -e eth0 -m 00:50:c2:85:30:9c -d 16 -f 519e6 -g 70 -N 25000 atsc_data_6-4m_complex You probably still need fast disks to take the data, like a raid-0 set of striped sata drives. Make sure there are no or very few Ou overruns. Saving the raw usrp data in 'short' form halves the disk space/bus bandwidth that the usual complex form uses. 3) Make pipes: mkfifo /tmp/atsc_pipe_1 mkfifo /tmp/atsc_pipe_2 mkfifo /tmp/atsc_pipe_3 mkfifo /tmp/atsc_pipe_4 mkfifo /tmp/atsc_pipe_5 4) In seperate windows run processes: ./interp_short.py ./xlate.py ./fpll.py ./btl-fsd.py ./viterbi-out.py When I execute step 4, the scripts appear to execute properly. When I go to the /tmp directory I do not see the pipes filling, the sizes remains 0. When I stop the execution of the scripts I do not have any data in my output file. Am I missing a step with piping the files. If I remove the pipes and execute the files sequentially (without any pipes). First executing ./interp_short.py then ./xlate.py a few seconds later and so on. I see the files (/tmp/atsc_pipe_(1-3) growing but not /tmp/atsc_pipe_5. The 'btl-fsd.py'script is not saving data to /tmp/atsc_pipe_5. I could use a little insight in executing this process. Thank You ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc data sample file needed
does anyone have atsc data captured by the usrp that i can download. Thanks Achjilleas ___ 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
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 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
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
> 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
[Discuss-gnuradio] ATSC demod tips
I just got a USRP, and I'm learning how it works. I'm having trouble getting the ATSC demod to work. The WFM demod works OK, so I know the antenna, etc works. I know I'm tuning the right frequency (KQED with a center frequency of 569MHz), because I can see the signal with usrp_fft. I got a few underruns during the "usrp_rx_cfile". About 10 in 10 seconds. The raw data file is 446 meg. I get an empty output file and a file named "taps.txt", which is also empty. I tried both the Gnuradio v3.1.2 (in Fedora 9) and the Gnuradio from SVN. I get a few output strings, like ">>> gr_fir_fff: using SSE" from btl-fsd and ">>> gr_fir_fff: using SSE Setting initial_freq: 3065000.00" from fpll Do you have any tips on finding the problem? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc svn update in private branch
FWIW I put all my latest atsc stuff in: http://gnuradio.org/svn/gnuradio/branches/developers/cswiger/wip including a recent elimination of another fir filter by making the input root-raised-cosine filter interpolate by 2 - that in itself takes one 1.8GHz Opteron cpu load from 84 to 40%. cpll runs at 16Mhz. One thing you need to do is redo gnuradio-core/src/lib/filter/interpolator_taps.h using gnuradio-core/src/gen_interpolator_taps/gen_interpolator_taps -n 128 -t 12 -B .375 > ../lib/filter/interpolator_taps.h and to build /that/ you need to ./configure --enable-fortran --Chuck ___ 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
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
[Discuss-gnuradio] ATSC
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
[Discuss-gnuradio] ATSC at the code repository
Hello, beside trying to solve my still existing problem to build wxgui I tried to set up the atsc transmitter/receiver as listed in the README.signal_flow, but I'm not able to find several blocks. I couldn't find GRWeaverModHead VSB modulator and GRWeaverModTail VSB modulator. The following question is, if I can use the "standard" mapping block from gnuradio, or there is a special block for atsc. Searching the mailing list I found a thread discussing to port the stuff to version 2.x/3.x. Did that happen? Can anybody help? Benedikt _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=0066 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC modulation
Hi guys, I am interested in being able to generate ATSC/8VSB modulation and/or playback a sampled ATSC/8VSB signal. The modulation calculation does not need to be real time and can be calculated off-line. The playback of the pre-calculated modulation would be real-time and loop the short burst of samples. What DAC resolution and frequency would be needed for real time playback of 8VSB modulated onto a 44MHz IF carrier? Can you recommend off-the-shelf DAC hardware that would be able to do this? I can configure an embedded processor we have here to output an 8-16bit word at 250-300MHz - would a crude resistor ladder DAC work or would it need a good silicon DAC? Thanks, Nick ___ 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 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?
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?
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 > R&D 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 Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote: > I am quite interested in the ATSC project due to some previous HDTV > R&D 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] ATSC real-time application?
I am quite interested in the ATSC project due to some previous HDTV R&D 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? 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. Thanks Kyle Zhou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc speed boost
On Thu, 2006-05-18 at 17:56 -0700, Eric Blossom wrote: > On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote: > > 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, > Now you're getting closer. If you start with the complex baseband > from the USRP, and rework the FPLL so that it works with complex > input, you can get rid of a bunch more ;) > Well, at this point I'm pretty much stuck as I'm: 1) unable to port the bit-timing to fs-demux chain - eyes glaze over, just don't understand everything going on to finish the job, particularly how to deal with inputs[0].index in the 2.x framework, and 2) no luck breaking up the 0.9 bt to fs-demux, more involved mucking around the old code would be required (which we want to avoid) So at this point that streach of code takes up the most cpu and no further optimizing is possible untill that is resolved, only using 3/4 of all available cpu. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc speed boost
On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote: > 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 Now you're getting closer. If you start with the complex baseband from the USRP, and rework the FPLL so that it works with complex input, you can get rid of a bunch more ;) Eric ___ 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
[Discuss-gnuradio] atsc speed boost
This works a bit more effeciently in matching a usrp to the atsc code (either all 0.9, or part 0.9 and part 2.x): Instead of: collect data with usrp decim = 8, then interp by 5 (8Msps to 40) then decim by 2 (40Msps to 20) while upshifting to 5.75MHz - 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 atsc_rx.cc, set input_rate to 19.2e6 (IR_20 = 19.2 instead of 20e6), and there is also needed a little tweak in GrBitTimingLoop3.cc and atsc_sssr.cc to get past the sanity checks for ratio of receiver clock to symbol rate, change the 1.8 to 1.78, it's *just* under the limit ;) ( 19.2 / 10.76 ). This puts the bottleneck back on the modified lt-atsc_rx process, which includes bit_timing_loop, fs_checker, equalizer and field_sync_demux. I should be able to split those up and manually redistribute the load a little better still. With that it's up from 1MiB / 6 seconds to about 1.2 or 1.3, or at least 20% faster, plus it takes 20% less disk space recording the signal ( before, a two hour movie would *just* fit on two striped 220GB disks using decim=8, with 5GB left ;) --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
[Discuss-gnuradio] atsc signal plots
Here's some pictures for Friday - I though these were interesting, the output of the 0.9 atsc equalizer showing the 8 levels getting more distinct with every field: http://webpages.charter.net/cswiger/g09_eq_data-1.jpg Zooming in: http://webpages.charter.net/cswiger/g09_eq_data-2.jpg shows the field sync which is largely made up of only +5/-5, and zooming in on the beginning: http://webpages.charter.net/cswiger/g09_eq_data-3.jpg you can make out the +5 -5 -5 +5 segment sync, followed by the start of the pn511 pattern (7 -5's, +5, -5, then 8 +5's). 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc runs up to field sync demux
Gang - just committed latest attempts to gr-atsc 2.x in cvs, updating atsc_bit_timing_loop, fs_checker, equalizer and field_sync_demux. Using an off-the-air signal they pass data down to field_sync_demux, which just scans for a valid field sync and that's as far as it goes. Anyway it's pretty tenuous - I'm not sure how to proceed. Will probably just let it percolate for a while and play around with sticking fprintf's here and there. The last one I put in fs_checker_naive produced this: >>> gr_fir_fff: using SSE Press Enter to StopFSC_naive: 511 pattern good, errors: 0 FSC_naive: 511 pattern good, errors: 9 !!! atsci_fs_checker_naive: PN63 error count = 37 FSC_naive: 511 pattern good, errors: 0 FSC_naive: 511 pattern good, errors: 0 FSC_naive: 511 pattern good, errors: 1 FSC_naive: 511 pattern good, errors: 0 FSC_naive: 511 pattern good, errors: 2 FSC_naive: 511 pattern good, errors: 16 FSC_naive: 511 pattern good, errors: 6 !!! atsci_fs_checker_naive: PN63 error count = 32 FSC_naive: 511 pattern good, errors: 0 I'm amazed that much works ;)) --Chuck ___ 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
[Discuss-gnuradio] atsc - field sync mux/demux questions
some questions toward porting GrAtscFieldSyncMux/Demux:
1) Is there a good concrete example for using 'forecast'?
it will be necessary since a FIELD SYNC field is (IIUC) a special
equalizer training and info field inserted every 312 data segments,
so the mux will take in 624 ds and output 626 ds. Also is there
a "sampling frequency" to jack up by 313/312 like in the 0.9 version?
2) What is the 2.0 version of type VrSampleIndex ? Tracked it
back to
typedef unsigned long long VrSampleIndex;
in VrTypes.h. Maybe gr_uint64 from gr_types.h ?
There's (lots) more but I think using forecast is the thing to focus on
for now.
I see in gr_block.cc there's:
void
gr_block::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for (unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = noutput_items;
}
and in gr_sync_block.cc it's:
void
gr_sync_block::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
unsigned ninputs = ninput_items_required.size();
for (unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = fixed_rate_noutput_to_ninput
(noutput_items);
}
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC changes
The ATSC has published revisions of several key standards--including A/52, the Digital Audio Compression Standard (AC-3); A/53, the Digital Television Standard; and A/110, the Synchronization Standard for Distributed Transmission. New versions of all three documents were approved by the ATSC membership this summer and are now available on the ATSC Web site. http://www.tvtechnology.com/features/atsc/f_jerry_whitaker.shtml ___ 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
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=MDL101546&feature_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
[Discuss-gnuradio] atsc receiver error rate: 5.19e-05
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
