;
Date: Mon, Apr 24, 2017 at 7:12 AM
Subject: Re: [Discuss-gnuradio] ATSC Decode Issues
To: Ron Economos <w...@comcast.net>
I was playing with the no_pfb version of the flowgraph again now trying to
work on getting an input signal to a file and I had a couple of other
questions about the ATSC p
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
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,
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
On Tue, Oct 15, 2013 at 10:01 PM, Ethan Trewhitt
gnura...@potophobia.net wrote:
As a part of my quest to understand some of the examples in GR (and
eventually contribute some well-commented GRC examples of my own),
I've been messing around with the atsc_rx.py script. Unfortunately,
since I
, August 05, 2013 3:37 PM
*To:* M. Ranganathan
*Cc:* GNURadio Discussion List
*Subject:* Re: [Discuss-gnuradio] ATSC fixups
** **
OK, pushed, could you see if that works better?
** **
Thank you
Andrew
** **
On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis glneolistm
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:
It was removed and left in fpll.h, i'll push a fix in just a bit, in
the meantime you could just remove the include line from fpll.h
Thank you
Andrew
On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan mra...@gmail.com wrote:
Hello,
I git cloned the atscfixup branch and tried building it. Here's
OK, pushed, could you see if that works better?
Thank you
Andrew
On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis glneolistm...@gmail.comwrote:
It was removed and left in fpll.h, i'll push a fix in just a bit, in
the meantime you could just remove the include line from fpll.h
Thank you
Andrew
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 ),
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
On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis glneolistm...@gmail.comwrote:
Hello all,
I'm working on fixing up gr-atsc and I have been working on a little
problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST )
that sets the reference for an AGC, the value is ( 2.5 *
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
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
On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis glneolistm...@gmail.comwrote:
I have been working on getting gr-atsc running again, I have found a few
speedups and some bugs that prevented ATSC decoding from working with new
versions of GNURadio. I have put these fixes into a branch that can
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
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.
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
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
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
On Thu, Feb 16, 2012 at 4:43 PM, Nick Foster n...@ettus.com wrote:
No, I don't know where that is... I can always take more data though. I'll
post it on a Dropbox tonight or this weekend. I'm pretty sure the Gnuradio
ATSC decoder is suffering from some massive bitrot though. If you do get it
On Fri, Feb 17, 2012 at 08:31, Tom Rondeau t...@trondeau.com wrote:
Also, we might be able to host some data files on gnuradio.org. I need to
look into how much space we have or can set aside for this, but it would be
nice to have stuff like this easily accessible.
We can easily conjure up an
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
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!
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
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
Tom Rondeau trondeau1...@gmail.com 04/20/10 9:58 AM
On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch bran...@auburn.edu wrote:
Hello everyone,
I am part of Auburn University's Software Defined Radio Senior Design team,
Software being used:
Ubuntu v.9.10 on xfs partition
GNURadio v.3.3
On Wed, Apr 21, 2010 at 3:48 PM, Stephen Branch bran...@auburn.edu wrote:
Hi Tom,
Thanks for the response.
Just for clarification:
You said:
For the channel you're looking at (20), the carrier would be at 507.31
MHz. There's a PLL to lock to the carrier, but I'm not sure if it's
broad
On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch bran...@auburn.edu wrote:
Hello everyone,
I am part of Auburn University's Software Defined Radio Senior Design team,
Software being used:
Ubuntu v.9.10 on xfs partition
GNURadio v.3.3 (git)
Xine
Available hardware: USRP1, USRP2, WBX
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.
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
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:
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
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
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
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)
On Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote:
I am quite interested in the ATSC project due to some previous HDTV
RD experience.
I am not quite sure about the current status of this project.
According to my understanding, ATSC has a very high throughput
requirement with a symbol
-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] ATSC real-time application?
On Sat, 2006-10-28 at 01:19 +1000, Kyle Zhou wrote:
I am quite interested in the ATSC project due to some previous HDTV
RD experience.
I am not quite sure about the current status of this project.
According to my
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
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
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
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.
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
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
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
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
As a side note, if you want to keep the program in HD you can burn the
MPEG program on a standard red-laser DVD and play them with this DVD
player:
http://pro.jvc.com/prof/attributes/press_res.jsp?model_id=MDL101546feature_id=08
You'll have to burn it as a DL disc, but 8 MB would fit. You can
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
48 matches
Mail list logo
