On Thu, 2008-07-17 at 07:55 -0700, Eric Blossom wrote:
> I've checked in an SMP-aware scheduler and would love folks to start
> testing with it. I'm seeing good scaling performance when running it
mp-sched cross compiles to the ps3 ok. You have to build boost 1.35 on
the ps3 (does not take long)
On Wed, 2008-07-09 at 14:26 -0700, Eric Blossom wrote:
> On Wed, Jul 09, 2008 at 04:38:20PM -0400, Charles Swiger wrote:
> > Here is a patch to add windowing to
> > gcell/src/lib/wrapper/spu/gcs_fft_1d_r2.c , seems quick and snappy:
> No need for all this shuffling...
>
On Wed, 2008-07-09 at 16:38 -0400, Charles Swiger wrote:
> Here is a patch to add windowing to
> It will also break gr-gcell/src/qa_fft.py
>
Actually it will not, window not used there.
--Chuck
___
Discuss-gnuradio mailing list
Discuss
Here is a patch to add windowing to
gcell/src/lib/wrapper/spu/gcs_fft_1d_r2.c , seems quick and snappy:
24a25
> #include
50a52
>
52,53c54,69
< // FIXME pointwise multiply in *= window
< assert(0);
---
> /* pointwise multiply: in *= window
> *
> * shuffle pattern to make
On Tue, 2008-07-01 at 20:08 -0400, Charles Swiger wrote:
> On Tue, 2008-07-01 at 20:00 -0400, Charles Swiger wrote:
> > Ok - I've redone this several times with variations; this last time was
> > very carefuly 'by the book' and I run into this after a fresh fc8,
On Tue, 2008-07-01 at 20:00 -0400, Charles Swiger wrote:
> Ok - I've redone this several times with variations; this last time was
> very carefuly 'by the book' and I run into this after a fresh fc8,
> updates, sdk3.0, Devel Tools, kernel 2.6.25.6-27.fc
On Tue, 2008-07-01 at 15:22 -0700, Eric Blossom wrote:
> On Tue, Jul 01, 2008 at 06:05:28PM -0400, Charles Swiger wrote:
> > Just need a clearification: the gnuradio FC8 installation procedure
> >
> > http://gnuradio.utah.edu/trac/wiki/PS3FC8Install
> >
> Yes. Tha
Just need a clearification: the gnuradio FC8 installation procedure
http://gnuradio.utah.edu/trac/wiki/PS3FC8Install
says to put
exclude=blas blas-devel oprofile-debuginfo oprofile numactl nuactl-devel
in /etc/yum.conf, but the SDK3.0 installation guide, on p.35 at the
bottom states to remove a
Playing with gr-gcell/src/qa_fft.py and seeing if it can be made to
handle more than one size=32 fft. If I simply double the input data so
it gets 2 chunks, I get a segmentation fault. Might this be the same
thing as the 'make check' on Fedora7 issue?
This works fine:
---
ph
Just poking around - since atsci_equalizer_lms::filter1 is at the top of
the oprofile report, I tried setting NTAPS to 64 instead of 256 and that
certainly made it faster, and decoding still turns in zero errors on an
excellent signal.
NTAPS 256:
samples %app name
On Sat, 2008-06-21 at 11:07 -0700, Eric Blossom wrote:
> On Sat, Jun 21, 2008 at 11:01:22AM -0400, Charles Swiger wrote:
> > the bit_timing_loop for 16MHz? I'll check in what I have
>
> Please do this on a branch.
>
Ok.
> > static const double BANDWIDT
On Fri, 2008-06-20 at 13:45 -0700, Eric Blossom wrote:
> considerably more up-to-date than that in 3.1.1. Chuck Swiger has
> been working on it.
>
> Eric
Ah, I still need to check in the complex pll stuff that gets rid of
> gr_freq_xlating_fir_filter_ccf 2.68%
and allows the pll to run at 16M
On Sat, 2008-05-31 at 13:45 -0400, Charles Swiger wrote:
> 'make check' fails with a segfault in 'gcell/src/apps/test_all'.
played around with gdb and finally found this while stepping:
Breakpoint 17, ~worker_ctx (this=0xf7e0071c) at
gc_job_manager_impl.cc:1241
1241 i
Here's what I found on the ps3 system so far:
Current system software is 2.35 and had to use a later
'CELL-Linux-CL-20080201-ADDON.iso' otherwise got a blank screen on
'start other os'. 20071023 is the version in the wiki, I'll try to
update things at some time.
Kernel 2.6.21 works fine but has t
On Sat, 2008-05-24 at 21:13 -0400, Achilleas Anastasopoulos wrote:
> Chuck, Eric,
>
> I think there is a way to perform the cPLL at 8 complex Msps and
> upsample to 16Msps only at the very end when you want to get the Real
> signal out for further processing. I believe this works (i didn't see
On Thu, 2008-05-22 at 22:53 -0400, Achilleas Anastasopoulos wrote:
> Chuck,
>
> I have a question regarding the comment you made in an earlier email on
> the subject:
>
> You said:
> -
> Now my question: Is it possible to tune the usrp so the carrier is at
> +.31 Mhz ? (band center a
On Tue, 2008-05-20 at 21:55 -0400, Brian Padalino wrote:
> On Tue, May 20, 2008 at 9:38 PM, Charles Swiger <[EMAIL PROTECTED]> wrote:
> > The issue turned out to be jiggering the numbers that say "I strongly
> > suggest that you not mess with these..." * by .
On Tue, 2008-05-20 at 21:00 -0400, Brian Padalino wrote:
> On Tue, May 20, 2008 at 8:52 PM, Charles Swiger <[EMAIL PROTECTED]> wrote:
> >
> > gr_complex IQ = input * gr_complex(a_cos,-a_sin);
> >
> > which would be necessary to handle negative frequencies I thin
After converting atsc_fpll to handle complex input (to eliminate one
upconverter) it almost works, only the video out has problems.
The problem starts when this:
float I = input.real() * a_sin;
float Q = input.real() * a_cos;
is changed to this:
gr_complex IQ = input * gr_complex(a_cos,-a
Is gr.pll_carriertracking_cc a suitable replacement for atsc_fpll? The
atsc one appears to have a loop filter that the carriertracking one does
not:
atsc_fpll:
float input = agc.scale (in[k]);
nco.step ();// increment phase
nco.sincos (&a_sin, &a_cos); // compute cos
On 17.11.2006 19:45 Eric Blossom wrote:
> Re: PS3/Cell BE platform
>
>
> Sounds like fun.
>
> And yes, I think we could get the HDTV receiver running in real time ;)
>
> Eric
>
>
In light of the experience gained since then, is that still a reasonably
attainable goal?
The only thing stop
On Wed, 2007-11-07 at 07:02 -0800, Firas abbas wrote:
> Hi,
>
> Are you going to put all your old articles about gnuradio and USRP
> which was exist on the old web site
> (http://webpages.charter.net/cswiger) and put it int he new one ?
>
Easy enough: http://www.swigerco.com/gnuradio/
with t
Hey all - There's an interesting bit in the November "Monitoring
Times" (p.32) about "Monitoring 192 kHz of Spectrum at a Time",
promoting the use of the RFSpace SDR-14 in swl'ing.
I'm just moving into an RF quiet rental house in the woods (yah!) with
lots of trees for antennas and it's the begin
On Wed, 2007-08-15 at 22:54 -0500, Jeff Brower wrote:
> Michael-
>
> > I think the most comprehensive page I've found is < http://
> > en.wikipedia.org/wiki/XMax >. Links to patents and reviews (e.g.
> > Phil Karn's). - MLD
>
> Phil Karn is a Qualcomm employee -- maybe not the most impartial sou
Apologies for general/off topicness, but does anybody have any
comments/opionion about these guys:
http://www.xgtechnology.com/technology.asp
Useful innovation or snake oil?
TIA
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
h
On Fri, 2007-06-01 at 15:46 +0200, Martin Dvh wrote:
> Hi Charles,
>
> In my bookmarks and Searching the gnuradio list I reguralary find messages by
> you with links to your homepage.
> http://webpages.charter.net/cswiger/
>
> But you homepage seems to be down or maybe moved:
>
Yes - charter w
On Thu, 2007-05-10 at 01:02 -0400, Charles Swiger wrote:
> Does anybody have or point to an example of overriding MainLoop() in wx
> Python Apps (wx.App.MainLoop) ?
>
nevermind - I finally found MainLoop on an obscure blog:
http://www.notes.xythian.net/2004/12/15/twisted-wxpython/
a
Does anybody have or point to an example of overriding MainLoop() in wx
Python Apps (wx.App.MainLoop) ?
I want to use usrp_spectrum_sense.py in a GUI app, and need to add some
code to MainLoop to get the spectrum data (the main loop in
spectrum_sense). A timer event will handle processing and d
On Sun, 2007-05-06 at 10:59 -0400, Eric A. Cottrell wrote:
> Hello,
>
> Is there a off-the-shelf product to power the USRP from 13.8 volts? My
> understanding is the USRP needs a couple of amperes at 6 volts. The
> best I saw was 1 Ampere maximum output.
>
There's these from Jameco, YM12S05:
Here's a first try at plotting the output of usrp_spectrum_sense.py
data, using 256 wxPython gauges to cover 500Mhz:
http://musicriver.homeunix.com:8737/satmon_1.jpg
That's G10R horizontal, the beacon at 11701 is clear on the left, 11270,
11800, etc.
The idea is to have something to monitor a
On Fri, 2007-04-27 at 13:06 -0400, Charles Swiger wrote:
> On Fri, 2007-04-27 at 08:48 -0700, Eric Blossom wrote:
> > On Fri, Apr 27, 2007 at 10:15:35AM -0400, Chuck Swiger wrote:
> > > The 2.x version of atsc_field_sync_demux has been proven to work.
> > >
>
> &
On Fri, 2007-04-27 at 08:48 -0700, Eric Blossom wrote:
> On Fri, Apr 27, 2007 at 10:15:35AM -0400, Chuck Swiger wrote:
> > The 2.x version of atsc_field_sync_demux has been proven to work.
> >
> I'll take a look at this as soon as I finish with the USRP power
> management problem.
>
Actually I
The 2.x version of atsc_field_sync_demux has been proven to work.
The equalizer still looks like an issue with symbol/tag alignment -
A working 0.9 system demux syncs on a (FIELD-2) at 3277436, while a
failing 2.x system syncs at 3277487 - a difference of exactly
d_offset = ntaps - npretaps - 1 (
How does 'history' relate to i/o data indices? I assume you cannot have
an index < zero.
Say your work function gets common i/o arrays
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
and you set_history(ntaps), I guess that means you get ( noutput_it
On Wed, 2007-04-25 at 08:12 -0700, Eric Blossom wrote:
> On Wed, Apr 25, 2007 at 11:02:13AM -0400, Chuck Swiger wrote:
> > The 2.x gr-atsc seems to be closer to working, at least the flow control
> > (forecast,consume,etc) creates the exact to-the-byte correct quantity of
> > output with no loss of
On Wed, 2007-04-25 at 08:12 -0700, Eric Blossom wrote:
> On Wed, Apr 25, 2007 at 11:02:13AM -0400, Chuck Swiger wrote:
> > The 2.x gr-atsc seems to be closer to working, at least the flow control
> > (forecast,consume,etc) creates the exact to-the-byte correct quantity of
> > output with no loss of
The 2.x gr-atsc seems to be closer to working, at least the flow control
(forecast,consume,etc) creates the exact to-the-byte correct quantity of
output with no loss of sync (since it keys on easy to discern -5/+5), on
120MB size output files.
However the *quality* of the output is only about 65 p
( retrying due to dns/email errors )
On Fri, 2007-04-13 at 13:32 -0700, Matt Ettus wrote:
> konvak wrote:
> > hello all,
> > I am thinking about building loop antenna for 3-6 MHz
> > to receive some DRM stations. As I understand it the loop antenna is
> > parallel
> I think
On Mon, 2007-01-01 at 16:17 -0500, John Ackermann N8UR wrote:
> for the higher bands. One version of the amp chip I'm using (a
> Mini-Circuits 3rd generation monolithic amp called a "GALI") has about
I just cracked open a Ramsey PR-2. The secret sauce is a upc1678,
available at mouser for $2.50.
On Mon, 2007-01-01 at 13:41 -0500, John Ackermann N8UR wrote:
> As mentioned earlier, I'm working on a front-end board for the Basic-RX
> to provide some gain and selectivity for HF use.
>
> Question -- has anyone figured out what sort of gain is optimum ahead of
> the the Basic-RX for use as an H
On Fri, 2006-12-29 at 19:24 +0100, Matteo Campanella wrote:
> Search the list on the subject - I did a posting some time ago about using
> DRM decoder with USRP bymeans of tmpfs ram based named pipe for interface...
>
> have a happy new year all
Oh - thanks to all replies, always interestin
Hi Gang - Did somebody have the DRM decoder working with a gnuradio
receiver? The main issue is feeding the sound from gnuradio into DReaM,
somehow, other than using two soundcards. I have DReaM 1.6.25 compiled.
http://sourceforge.net/projects/drm/
TIA
--Chuck
__
On Mon, 2006-11-06 at 09:34 -0800, Eric Blossom wrote:
> Chuck,
>
> Can you please remind me where the ATSC Rx porting effort got stuck?
> What's the immediate problem that needs to be solved?
>
Everything from antenna to the "bit timing loop" can be done in
2.x, including fpll. The bit timing
On Fri, 2006-11-03 at 11:25 -0500, Berkley, Antwong L. wrote:
> I want to build a SDR that can capture an HDTV (non-real time) and
> then transmits. I have a USRP and the Rx daughterboards. Are there
> any up to date HowTo’s on Building a HDTV Rx using USRP.?
>
>
>
> Do I have to buy any add
Ok, a rough atsc transmitter benchmark: as it is now with almost
all the signal processing still taking place in the 0.9 code, that
is, one processor running 100% and the 2.0 script in the single
digit percent utilization - a 9 second mpeg stream takes 104
seconds to encode. Using 2GHz Opterons.
Gang - I've been playing with the atsc transmitter and have a few notes
to report.
First, a good definition of "real time transmitter" would include a
firewire video camera, the processing to make an mpeg transport stream
(whatever that is, I'm not a video guy), then the atsc_tx out to the
usrp a
On Tue, 2006-10-31 at 13:53 -0800, Matt Ettus wrote:
> [EMAIL PROTECTED] wrote:
> > does this mean that the 64-bit gr_complex float is converted to integers
> > (16bit
> > I and 16bit Q) when it
> > gets to the USRP? This seems odd to me (but that could just be me not
> > understanding), so I was
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 :)
> >
>
> Ac
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.
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 ra
On Tue, 2006-10-24 at 16:07 +1000, Kyle Zhou wrote:
> Is there anything wrong with my configuration or the atsc module is
> not completely implemented?
> Thanks
> Kyle
Yes, the atsc 2.x module is not completely implemented.
I played around with it earlier this year, and some of the modules
work i
Some list members might be interested in these web seminars, esp.
IF Modem Design:
http://seminar2.techonline.com/s/altera_nov06_series
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss
On Tue, 2006-09-19 at 15:06 -0700, Eric Blossom wrote:
> gr.file_source has a seek method which will allow you to seek
> instantly anywhere in the file.
>
Yep - I use that all the time. The extra challenge was to put
time-stamping information in a data file using Cooley's file
headers
http://
On Tue, 2006-09-19 at 13:28 -0400, Charles Swiger wrote:
> On Tue, 2006-09-19 at 11:45 -0400, Charles Swiger wrote:
> > I just used Jim Cooley's file headers to put timestamps in my
> > shortwave radio data so when I play back a pirate radio broadcast
> > I can see t
On Tue, 2006-09-19 at 11:45 -0400, Charles Swiger wrote:
> I just used Jim Cooley's file headers to put timestamps in my
> shortwave radio data so when I play back a pirate radio broadcast
> I can see that, hey, that was on last Saturday at 8:15PM. The
> gui now sports a clo
There was discussion once about file formats for saved data.
I just used Jim Cooley's file headers to put timestamps in my
shortwave radio data so when I play back a pirate radio broadcast
I can see that, hey, that was on last Saturday at 8:15PM. The
gui now sports a clock showing either current o
On Tue, 2006-08-29 at 14:06 +0200, Carlo E. Prelz wrote:
> I decided to engage in a project whose target is to detect the
> existing cell-phone traffic in a specific surrounding and represent it
> in some visually or acoustically interesting way. This is a personal
Carlo got me interested in makin
On Wed, 2006-08-30 at 09:24 +0100, mat holton wrote:
> Hi there everyone,
>
> I sent Eric and email asking if it was possible to record the entire
> spectrum and about the possibilities that would result if this was
> possible. After an excellent reply, I continued and he suggested I post
> her
On Fri, 2006-08-11 at 07:02 -0700, Johnathan Corgan wrote:
> Charles Swiger wrote:
> > That's ok, there's, um, some issue with make check. Did "make install"
> > and simple graphs do run alright, but for "make check" :
> >
> >
> > m
On Thu, 2006-08-10 at 11:56 -0700, Johnathan Corgan wrote:
> Ticket #13 was reporting failure with parallel makes.
>
> This was failing in gnuradio-core, but was fixed back in r3222.
>
> Those of you tracking the new svn trunk--could you test this and confirm?
>
I tried the svn source with "mak
On Mon, 2006-07-24 at 10:25 -0700, Eric Blossom wrote:
> Chunk, thanks for posting a work-around.
>
> I *really* suggest that you guys sort this out properly and generate a
> patch that fixes it. Otherwise this kludge is going to get
> propagated. You really don't want to be copying files aroun
On Sun, 2006-07-23 at 12:04 -0400, Eric Hill Matlis wrote:
> I can confirm a successful install of gnuradio cvs to my 32-bit
> Fedora Core 5 system, as dial_tone.py works. So my issues with the
> the x86_64 system seem to be related to the location of the 32 and 64-bit
> libraries.
>
> hopefu
On Tue, 2006-07-18 at 08:57 -0700, Angilberto Muniz Sb wrote:
> Folks,
> I'm confused with -i option in siggen.py...
>
> If I want to generate a pure 1MHz sine wave centered
> at 10MHz carrier is it correct to use:
>
> siggen.py --const --sine -f 1e6 -c 10e6
>
> or should I use:
>
> siggen.py -
All - Do I understand correctly that gr.pll_carriertracking_cc() is
supposed to downconvert to DC? I don't see it doing that, and can't
see in the work functions where that magic would be accomplished.
Just want to make sure I'm building the most efficient graph possible.
I tried both in an exist
On Wed, 2006-07-05 at 09:39 -0700, Eric Blossom wrote:
> On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
> > I'm curious about this statement in
> > $PYTHONPATH/gnuradio/gr/flow_graph.py
> >
> > # We could scan the graph here and determine individual sizes
> > # based
On Wed, 2006-07-05 at 09:39 -0700, Eric Blossom wrote:
> On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
> >
> > Because: One of my simple test apps works 600% faster using 4k buffer
> > instead of 32k, since it doesn't have to wait for stale data to clear.
>
> Chuck, can you point
I'm curious about this statement in
$PYTHONPATH/gnuradio/gr/flow_graph.py
# We could scan the graph here and determine individual sizes
# based on relative_rate, number of readers, etc.
In the meantime, it would be nice to be able, somehow, to tweak the
global buffer size from in
On Tue, 2006-06-27 at 11:18 -0400, Marcus Leech wrote:
> >
> There's an astronomically-important spectral line at
> 12.178Ghz--Methanol. Which will come out of your
> LNB at 1428Mhz. The M45 region of the sky produces Methanol masering
> outbursts on a regular basis.
> But you probably
On Mon, 2006-06-26 at 17:12 -0700, Matt Ettus wrote:
> >doesn't it look like the USB 2.0 is a heavily constraining bottleneck?
> >
> >
> Yes, USB2.0 is the bottleneck.
>
> >And, if I'm not wrong about this, will it be possible in the future to
> >have a USRP <--> PC interface which doesn't limit
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
> > > 1
Apologies if this is no longer supported - Does anybody remember
how to connected an upstream port 0 to a downstream port 1 in
gr0.9 ?
Trying to split up gr-atsc0.9, and want to connect a file source
to equalizer port 0, and another file source to equalizer port 1.
But from gr_FlowGraph.h, all w
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 c
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 inter
I just added atsc_depad to cvs gr-atsc.
The 2.x code worked thru derandomizer, but the output was
atsc_mpeg_packet padded out to 256, which xine/mplayer won't
play. Kludging atsc_mpeg_packet pad to 0 in atsc_types.h
worked with a warning from gnuradio about output not being
a power-of-2. atsc_de
On Tue, 2006-05-09 at 16:15 -0500, Brett L Trotter wrote:
> On this page:
> http://www.nabble.com/Automatic-testing---sweep-generator-t232617.html#a650444
>
> was a link to his sweeper, which seems to be defunct. Does anyone have a
> copy hosted somewhere?
>
Hi Brett - I'll send you what I have
On Mon, 2006-05-08 at 14:57 -0400, Charles Swiger wrote:
> the chain works, with some room for moving processes
> around and optimizing. For instance, the RF gets mixed
Yeah, splitting the resampling/translating block helped.
Just to put things in perspective, we're getting about
1MB o
It turns out to be not too awefully difficult (tho not officially
approved ;) to modify the gnuradio-0.9 atsc code to use a subset
of blocks, specifically everything from bit-timing-loop to
field-sync-demux (float in, soft-data-segments out). So here's
what I have working across 4 cpu's:
Start
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
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
On Thu, 2006-05-04 at 03:46 -0700, Eric Blossom wrote:
> On Wed, May 03, 2006 at 04:37:49PM -0400, Chuck Swiger wrote:
> > Will a 2.x block consume an input stream if it returns 0 output items?
>
> Yes, if it's based on gr_block and you call consume or consume_each
> in general_work.
>
Ok, just
On Wed, 2006-05-03 at 16:37 -0400, Charles Swiger wrote:
> Will a 2.x block consume an input stream if it returns 0 output items?
>
appearently not. I just make a simple change
d_next_input += ii; // update for forecast
return ii/DEC; // no work comple
Will a 2.x block consume an input stream if it returns 0 output items?
All the other atsc blocks are at least passing data and reporting
various states, but fsd = atsc.field_sync_demux() seems to be hung up.
An upstream block connected to fsd, when also connected to a file sink
only produces 28672
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 te
On Mon, 2006-05-01 at 15:05 -0700, Eric Blossom wrote:
> > but modern compilers deallocate the index when the loop
> > is completed (one web page says), so the fix is to use:
> >
> >
> > for (int k = 0; k < noutput_items; k++){
> > ...
> > out_sample[k] = interp_sample;
> > ...
> >
On Mon, 2006-05-01 at 10:38 -0700, Eric Blossom wrote:
> On Mon, May 01, 2006 at 12:08:57PM -0400, Chuck Swiger wrote:
> > Any general clues what would be causing:
> >
> > python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
> > int, unsigned int): Assertion `s < d_bufsize' failed
On Mon, 2006-05-01 at 12:19 -0700, jjw wrote:
> I have been digging through the code to try and understand the architecture
> that GNU Radio works on. From flow_graph.py I have come to the
> understanding that GNU radio creates and manages it's own memory buffering
> scheme. This would seem to ma
On Mon, 2006-05-01 at 10:38 -0700, Eric Blossom wrote:
> You're probably returning a value from work/general_work that's
> greater than nouput_items. Add an assert to you code.
>
Indeed - an fprintf shows:
ninput_items_required: 8597
ninput_items_required: 5048
noutput_items: 1910, Returning
Any general clues what would be causing:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int, unsigned int): Assertion `s < d_bufsize' failed.
I'm taking a closer look at atsc_bit_timing_loop.cc|h and trying
gr_sync_decimator in place of gr_sync_block, however that error oc
On Fri, 2006-04-28 at 15:16 -0400, Ilia Mirkin wrote:
> You need to figure out which interface is the right one, and use that.
>
In small repayment for your assistance, here's two screenshots. First
is a local station live off the air, in 20MSps float centered on
5.75Mhz:
http://webpages.charte
On Fri, 2006-04-28 at 15:16 -0400, Ilia Mirkin wrote:
> Usually when something like this happens, you have some versioning problems
> between interfaces. And indeed your files reveal this:
>
> .h:
>
> atsc_fpll_sptr atsc_make_fpll();
>
> .cc:
>
> atsc_fpll_sptr atsc_make_fpll(double a_initial_f
Any tips what could cause this, Python does not like the
'U'ndefined symbol.
.../gnuradio/_atsc.so: undefined symbol: _Z14atsc_make_fpllv
$ nm _atsc.so | grep atsc_make_fpll
0004e9c0 T _Z14atsc_make_fplld
U _Z14atsc_make_fpllv
Checking the .libs objects:
$ nm atsc_fpll.o | grep ats
On Fri, 2006-04-28 at 21:05 +0930, Berndt Josef Wulf wrote:
> G'day,
>
> Is "make check" in gr-atsc know to complete? It currently fails to complete
> with the following message.
>
> Making check in python
> make check-TESTS
> ...
> sched: is requesting more input data
> than we can provide.
On Thu, 2006-04-27 at 11:57 -0700, Eric Blossom wrote:
>
> Also, can you please post a brief status report about what's the next
> thing to get working? I'm not sure at this time what's needed to get
> get the next step of the loopback working.
>
Ok, I've added to gr-atsc cvs these files:
ats
On Wed, 2006-04-26 at 21:30 -0400, Ilia Mirkin wrote:
> Quoting Charles Swiger <[EMAIL PROTECTED]>:
>
> > On Wed, 2006-04-26 at 17:53 -0700, Eric Blossom wrote:
> >
> >>
> >> After taking a look at the 0.9 code (atsc_rx.cc), it looks like we w
On Wed, 2006-04-26 at 17:53 -0700, Eric Blossom wrote:
> Hi Ilia,
> Thanks for diving in.
>
> Chuck,
>
> After taking a look at the 0.9 code (atsc_rx.cc), it looks like we were
> instantiating atsci_equalizer_lms.
>
> atsci_equalizer_lms uses a single FIR filter.
>
> atsci_equalizer_lms2 uses
On Wed, 2006-04-26 at 17:09 -0400, Ilia Mirkin wrote:
> Quoting Charles Swiger <[EMAIL PROTECTED]>:
> > ./atsc_equalizer.h:41: error: cannot declare field
> > `atsc_equalizer::d_equalizer' to be of type `atsci_equalizer'
> > ./atsc_equalizer.h:41: error: be
This is more C++ than dsp - this compiles but segfaults:
atsc_equalizer.h:
---
class atsc_equalizer;
protected:
atsci_equalizer *d_equalizer;
atsc_equalizer.cc:
// peform the actual equalization
d
How do you declare two inputs of different data types?
Several atsc blocks pass a stream of 'float' and also 'syminfo'
(a struct of 4 ints).
>From what I can tell, gr_sync_block allows many inputs and outputs,
but only of the same type(?).
gr_block::gr_block (const std::string &name,
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
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.
1 - 100 of 143 matches
Mail list logo
