On Tue, 2009-07-28 at 20:47 -0700, Jane Chen wrote:
> According to the explaination of the In-band Signaling in the link
> http://gnuradio.org/trac/wiki /InBandSignaling, In-band Signaling is
> what I need for the MAC layer implementation.. I try to find more
> information about it on the mailingl
Hi all,
According to the explaination of the In-band Signaling in the link
http://gnuradio.org/trac/wiki /InBandSignaling, In-band Signaling is what I
need for the MAC layer implementation. I try to find more information about it
on the mailinglist or the Web. I am wondering if In-band Signalin
On Jan 12, 2008 6:01 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> Would any of the FIR filters that already exist in GR be appropriate? I
> could then perform the cross-correlation on the output of the block.
If you just give your known coefficients to the filter, then it really
just performs
Thanks Brian,
A matched filter is just a FIR filter that does correlation because
the coefficients are a specific sequence instead of a frequency
response. This is how CDMA works. You "spread" your one bit out over
this PN sequence and then use a matched filter to correlate against
the expect
On Dec 4, 2007 8:43 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> So there is no way of getting a generalized matched filter on the USRP?
>Is there anything that can be done to get around the hardware
> multipliers? If there is absolutely no way, limiting to GMSK, PSK, and
> QAM is not that b
You can't go lower than the PHY layer. There's a reason it's the
lowest on the stack.
Yeah, stupid comment by me ;)
You can use a matched filter for this, but a generalized matched
filter uses multipliers. If you limited yourself to GMSK, PSK, or QAM
you can get away with sign manipulation
On Dec 4, 2007 2:00 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> I see, I want to go lower than the PHY layer really...
You can't go lower than the PHY layer. There's a reason it's the
lowest on the stack.
> Here's the thing, I don't want the solution to be dependent on the
> physical layer.
You're not getting rid of the PHY layer. You're incorporating this
mechanism into the PHY layer as opposed to having it within the MAC
layer.
I see, I want to go lower than the PHY layer really...
You can accomplish this by using some simple sign manipulation/zero
insertion and treating t
On Dec 4, 2007 1:07 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> From some discussion on comp.dsp, it seems as though I'm looking for a
> matched filter:
> http://groups.google.com/group/comp.dsp/browse_thread/thread/f93d7867f74dbe95#0dc48f2a8ed09e07
Yes, you are describing a matched filter.
>
From some discussion on comp.dsp, it seems as though I'm looking for a
matched filter:
http://groups.google.com/group/comp.dsp/browse_thread/thread/f93d7867f74dbe95#0dc48f2a8ed09e07
If you see what I'm getting at, if I implement a matched filter in the
FPGA (given that it does what I think it d
I don't think I understand what you're trying to do here. What frames
were you transmitting? What pattern are you looking for? Do you hope
on performing this operation in the FPGA or on the host?
Sorry for my confusion.
No problem, I don't mind trying to be clear :)
Here's an *example*
On Dec 4, 2007 11:11 AM, George Nychis <[EMAIL PROTECTED]> wrote:
> As a first test, I used one USRP to continuously transmit frames, and
> another to dump the raw samples used to decode the frame sync bits of
> each frame. Based on 100 different sample dumps, I am finding
> absolutely no correlat
Is any sort of sample pattern matching possible in the slightest bit?
As a first test, I used one USRP to continuously transmit frames, and
another to dump the raw samples used to decode the frame sync bits of
each frame. Based on 100 different sample dumps, I am finding
absolutely no cor
Lets say for a TDMA MAC, there is a beaconing time that happens every
50ms for 1 ms and a 200us guard time between beacons for a specified
number of radios.
Can you setup a USRP to transmit some data every 50ms, and have a
second USRP lock on to that periodic 50ms transmission and be sure to
be
On Nov 27, 2007 10:43 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> To measure the round trip latency we used three USRPs... two in
> contention and a third monitoring. The two in contention would exchange
> the channel back and forth by reading the RSSI value from the incoming
> packets. To spa
The average was 1.96ms and sdev 0.62ms.
Sorry, I omitted the fact that this was calculated from 200 values.
- George
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Brian Padalino wrote:
A few questions:
- What is the current round trip latency for the in-band code?
To measure the round trip latency we used three USRPs... two in
contention and a third monitoring. The two in contention would exchange
the channel back and forth by reading the RSSI val
A few questions:
- What is the current round trip latency for the in-band code?
- Have you tried synchronizing two different USRPs to each other over the air?
- What is the minimum amount of turnaround time you're looking to achieve?
Brian
___
Di
Hi all,
I was looking to kick some discussion to the board to get some ideas
here. The in-band signaling code is likely to be used by many to
research MAC protocols, and one thing crucial to CSMA style protocols
are dependent packets which have very strict timing requirements. For
example,
Hi all,
I've gotten an e-mail asking what exactly is the in-band signaling
project, and since I'm asking for people to help contribute... I think
that's a fair question for me to answer :)
Overview:
We're making significant changes in GNU Radio and the USRP FPGA to
create a control channel
On Thu, Feb 15, 2007 at 03:33:42PM -0500, Brian Padalino wrote:
> I am real curious as to the ideas that have been thrown out on how to
> handle the in-band signaling to the USB and FPGA for the mblock system
> currently being worked on.
>
> If this is more appropriate to be off-list, that is fine
Hey Brian,
This is actually in discussion right now :)
Myself and another student are working with the platform with the long
term goal of developing fine grained MAC protocols, however we need the
functionality of the m-block and the tighter timing.
Therefore we've started our research proj
I am real curious as to the ideas that have been thrown out on how to
handle the in-band signaling to the USB and FPGA for the mblock system
currently being worked on.
If this is more appropriate to be off-list, that is fine - but I am
real curious and wouldn't mind helping out if I could. I kno
23 matches
Mail list logo
