On Mon, Feb 26, 2007 at 01:22:22AM -0500, David Scaperoth wrote:
> I am definitely interested in the capabilities of the in-band
> signaling, but my lack of experience is going to show through in this
> e-mail. =)
No problem.
> I am not sure I understand the meaning behind the 5-bit channel e
I am definitely interested in the capabilities of the in-band
signaling, but my lack of experience is going to show through in this
e-mail. =)
I am not sure I understand the meaning behind the 5-bit channel entry:
I thought that this might refer to channels within the total
bandwidth of the
On Sun, Feb 25, 2007 at 11:18:09PM -0500, Brian Padalino wrote:
> Sorry, I retract my previous statement. Sending 2 packets is
> obviously the thing to do. One with the control sequence with the
> beginning timestamp and the second with the beginning of the I/Q data.
>
> Sorry! Late night error
Looking at it again, maybe there should be an OP_START to either start
the RX or TX depending on it either being an IN or OUT packet?
Otherwise, how would you know when to actually begin performing the
desired action?
What do you think?
Brian
___
Dis
On Sun, Feb 25, 2007 at 09:12:23PM -0500, Brian Padalino wrote:
> On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> >I guess I'm concerned that some of the OPS could take more than a
> >single tick. E.g., I2C or SPI ops. Thoses buses run at something
> >like 100kHz to 400kHz. If all executio
On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
I guess I'm concerned that some of the OPS could take more than a
single tick. E.g., I2C or SPI ops. Thoses buses run at something
like 100kHz to 400kHz. If all execution delays are known, then
OP_DELAY seems fine (and easy).
I share the sa
On Sun, Feb 25, 2007 at 08:53:51PM -0500, Brian Padalino wrote:
> On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> >That sounds good. Would you interpret it as a delta-t from the
> >timestamp in the header? I'm thinking about the case where there are
> >multiple DELAY ops in the payload.
>
On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
That sounds good. Would you interpret it as a delta-t from the
timestamp in the header? I'm thinking about the case where there are
multiple DELAY ops in the payload.
It would probably be best to interpret it as a delta from the current
time
On Sun, Feb 25, 2007 at 08:33:23PM -0500, Brian Padalino wrote:
> >Would you prefer that both types of data occurred in the same packet?
> >
> >Eric
>
> Not at all - it makes much more sense to calculate when to bring up /
> tear down the RF stuff on the host rather than inside the FPGA and
> back
On Sun, Feb 25, 2007 at 08:30:19PM -0500, Brian Padalino wrote:
> On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> >My thinking behind this was to keep life simple for the common case:
> >If Chan != 0x1f, clock payload into appropriate signal processing pipeline.
> >If Chan == 0x1f, do the pot
On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
My thinking behind this was to keep life simple for the common case:
If Chan != 0x1f, clock payload into appropriate signal processing pipeline.
If Chan == 0x1f, do the potentially slow, complicated work...
Sorry - my misunderstanding. This m
The recent breakage of the linking problems on the trunk (which also got
back ported to the release branch) has a trial fix at:
http://gnuradio.org/svn/gnuradio/branches/developers/jcorgan/linking
A thorough clean up and "harmonization" has been done, with renamed
macros. Notably, all build depen
On Sun, Feb 25, 2007 at 05:28:47PM -0800, Eric Blossom wrote:
> On Sun, Feb 25, 2007 at 08:10:06PM -0500, Brian Padalino wrote:
> > On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> > >On Sun, Feb 25, 2007 at 07:29:01PM -0500, Brian Padalino wrote:
> > >> Some preliminary questions:
> > >>
> >
On Sun, Feb 25, 2007 at 08:10:06PM -0500, Brian Padalino wrote:
> On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> >On Sun, Feb 25, 2007 at 07:29:01PM -0500, Brian Padalino wrote:
> >> Some preliminary questions:
> >>
> >> How are the operations linked with the transmit sequences?
> >
> >I'm n
On 2/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Sun, Feb 25, 2007 at 07:29:01PM -0500, Brian Padalino wrote:
> Some preliminary questions:
>
> How are the operations linked with the transmit sequences?
I'm not sure I understand this question.
I am not sure how the operations being sent
On Sun, Feb 25, 2007 at 07:29:01PM -0500, Brian Padalino wrote:
> Some preliminary questions:
>
> How are the operations linked with the transmit sequences?
I'm not sure I understand this question.
> Are operations sent down in bulk, or one at a time?
You can send as many as will fit in the p
Some preliminary questions:
How are the operations linked with the transmit sequences? Are
operations sent down in bulk, or one at a time? Will the RX chain
simply start and return 504-byte length packets until the next TX
timestamp is sent down? Could this starve the USB bandwidth?
Brian
_
Would those of you with an interest in USRP inband signaling, please
take a look at the latest proposed packet format. Now's a good time
to change things ;)
It's in trunk/usrp/doc/inband-signaling-usb
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
Thanks,
Eric
_
On Sun, Feb 25, 2007 at 11:36:14PM +0100, Vincenzo Pellegrini wrote:
> In my previous installation, still on fedora core 6 I did not experience
> this but right now,
> when make checking into the src/python directory after having compiled the
> gr-howto-write-a-block stuff
>
> I get this error:
H
Vincenzo Pellegrini wrote:
> In my previous installation, still on fedora core 6 I did not experience
> this but right now,
> when make checking into the src/python directory after having compiled
> the gr-howto-write-a-block stuff
Not certain, but this may be a symptom of the linking breakage th
In my previous installation, still on fedora core 6 I did not experience
this but right now,
when make checking into the src/python directory after having compiled the
gr-howto-write-a-block stuff
I get this error:
ERROR: test_002_square2_ff (__main__.qa_howto)
--
Patrick,
I like the idea of having dynamic/automatic block importing. It was a
consideration from the beginning. However, I realized that there was no
way to "not" have to write some kind of definition for every block.
After my 0.5 version of GRC, I switched to this current "signal blocks
def
Eric Blossom wrote:
>> It may be that there is a -lfoo instead of libfoo.la in a Makefile
>> now.
>
> I believe that's the current problem. We used to always use
> libfoo.la. There was a recent change that added -lfoo in addition to
> libfoo.la.
This was done to fix ticket 138 on Win32 platf
On Sun, Feb 25, 2007 at 08:58:25AM -0500, Greg Troxel wrote:
> That sounds good to me, but if we're talking a major change,
Hopefully, this isn't a major change. I'm thinking that it's a bug
fix and the creation of developer documentation that says exactly how
we're linking everything and why.
I
On Sun, Feb 25, 2007 at 07:16:08PM +0100, Martin Dvh wrote:
> Eric Blossom wrote:
> >>
> >>The old wiki used to have categories which were handy for finding what you
> >>need.
> >>The new Wiki only has a quite bare homepage.
> >>You must know you have to click at TitleIndex to see all documents.
>
Eric Blossom wrote:
> On Sun, Feb 25, 2007 at 03:21:52PM +0100, Martin Dvh wrote:
>
>>Eric Blossom wrote:
>>
>>>On Mon, Nov 20, 2006 at 10:35:19AM -0500, Lamar Owen wrote:
>>>
>>>
On Saturday 18 November 2006 19:54, Berndt Josef Wulf wrote:
>where did the old GNU Radio Wiki go? I
On Sun, Feb 25, 2007 at 09:09:07AM -0800, Eric Blossom wrote:
>
> You can also search in the box at the top.
> To find all references to CategoryFoo, enter !CategoryFoo
> The explantion point keeps it from returning only the CategoryFoo page.
Uhh, make that "exclamation point ..."
Eric
_
On Sun, Feb 25, 2007 at 03:21:52PM +0100, Martin Dvh wrote:
> Eric Blossom wrote:
> > On Mon, Nov 20, 2006 at 10:35:19AM -0500, Lamar Owen wrote:
> >
> >>On Saturday 18 November 2006 19:54, Berndt Josef Wulf wrote:
> >>
> >>>where did the old GNU Radio Wiki go? I'm looking for the pages containing
Eric Blossom wrote:
> On Mon, Nov 20, 2006 at 10:35:19AM -0500, Lamar Owen wrote:
>
>>On Saturday 18 November 2006 19:54, Berndt Josef Wulf wrote:
>>
>>>where did the old GNU Radio Wiki go? I'm looking for the pages containing
>>>information on user applications, sample data files, howto files etc
Martin Dvh wrote:
> Rohit Gupta wrote:
>
>>Hi,
>>
>>We are working on using GNURadio for using it as RF node capable of
>>2*2/4*4 MIMO. All the RF nodes are connected to very big FPGA like the
>>one used in "Berkeley Emulation Engine (BEE)" using "Infiniband"
>>Optical Fiber. All the signal proces
That sounds good to me, but if we're talking a major change, I'd like
to throw out something somewhere between desire and requirement:
If a component A is enabled, but a GNU Radio component B that is a
dependency for A is not enabled (by configure), then build and make
check both use the ins
Rohit Gupta wrote:
> Hi,
>
> We are working on using GNURadio for using it as RF node capable of
> 2*2/4*4 MIMO. All the RF nodes are connected to very big FPGA like the
> one used in "Berkeley Emulation Engine (BEE)" using "Infiniband"
> Optical Fiber. All the signal processing is implemented in
32 matches
Mail list logo
