Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[Brian Padalino]

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 bad.  What makes OFDM need different processing?  I'm
> trying to read up on matched filters now.

There's always a way to do something, but you are resource limited.
You can write something that will use 1 complex multiplier and can do
a 64 tap matched filter at a symbol rate of 1Msps.  Or you can use 8
complex multipliers to do the same thing since the minimum decimation
of the USRP is 8.  You can slice it any way you want and do TDM on the
multipliers you infer or directly instantiate.  You can possibly even
generalize the RTL to be parameterized so anyone can re-build it and
re-program the FPGA with ease using their own matched filter.

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 expected PN sequence.  You can either get a 1 or a -1 depending if
you sent a 0 or a 1.

Wikipedia has good entries for both a matched filter and cross correlation.

http://en.wikipedia.org/wiki/Cross-correlation
http://en.wikipedia.org/wiki/Matched_filter

The reason OFDM is different is because the symbols are actually
presented in the frequency domain, so you have to perform an FFT on a
window of samples and read which tones are present.  Because there is
that extra step of taking the FFT first, the time domain samples are
pretty much useless by themselves.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Routing and Placing and Clock for FPGA !

[Brian Padalino]

On Dec 4, 2007 8:30 PM, Ronald Jetli <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Needed to confirm a few things:
>
> 1) Is the global clock frequency for USRP 64Mhz ?

Yes.  It's a fully synchronous design with FIFO boundaries where it
talks to the FX2 chip which runs at a different clock speed I believe.

> 2) Do we use this global clock frequency for FPGA on the USRP and not the
> FPGA's clock ? Because, I think the EP1C12Q240C8 FPGA runs at much higher
> clock speeds. So, we are using
> global clock to achieve synchronisation.

When the FPGA is routed, there isn't much more slack above the 64MHz
for Fmax (or so I thought).  I am not sure what you mean when you
state the part runs much higher clock speeds.

What do you mean by synchronization?  It is a little vague and ambiguous.

> 3) Also, is the automatic route and place tools provided by the Quartus
> software, being used for FPGA  ? While compiling, I see that automatic place
> and routing is happening. But still wanted to confirm if that is true or is
> it being manually configured (for already compiled rbfs) to achieve higher
> efficiency.

Quartus does all the work when translating the RTL into a programming file.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[George Nychis]

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 manipulations.  OFDM would require
different processing in general.

>

If some mechanism could be built in the FPGA that was highly
reconfigurable, that would be fine... but it seems to be boiling down to
different techniques per-modulation.


Not really an option for the USRP as it currently is due to the lack
of hardware multipliers.  Maybe more of an option for the USRP2.


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 bad.  What makes OFDM need different processing?  I'm 
trying to read up on matched filters now.




On a side note, you should not feel bad about making something that
considers a trade-off in the realm of software defined radio.  You are
giving up (slight) PHY layer flexibility for much improved latency.
We're still using an antenna.  We're still using a super heterodyne
receiver.  Some things just can't be software and are limitations -
working around them is fine.



I agree, it's not even that this functionality is truly needed.  The 
host can still be used to decode and generate ACKs.  It's merely an 
optional mechanism and certainly better than nothing.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Routing and Placing and Clock for FPGA !

[Ronald Jetli]

Hi,

Needed to confirm a few things:

1) Is the global clock frequency for USRP 64Mhz ?

2) Do we use this global clock frequency for FPGA on the USRP and not the
FPGA's clock ? Because, I think the EP1C12Q240C8 FPGA runs at much higher
clock speeds. So, we are using
global clock to achieve synchronisation.

3) Also, is the automatic route and place tools provided by the Quartus
software, being used for FPGA  ? While compiling, I see that automatic place
and routing is happening. But still wanted to confirm if that is true or is
it being manually configured (for already compiled rbfs) to achieve higher
efficiency.


Please correct me if I am wrong.

Jetli.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ettus usrp purchase problem

[Matt Ettus]

Engin,

This is not the forum for this.  We have responded to you several times, 
but you don't appear to be receiving our messages.  Perhaps it would be 
best if you called our office, at 1-650-967-2870.


Thanks,
Matt

Engin Karabulut wrote:
we have sent a purchase order to ettus sales mail([EMAIL PROTECTED]) in order 
to
purchase a usrp hardware. But neither this mail nor matt's mail respond to 
me.
I have to purchase until december 15, because our purchase department won't 
work

after this date for a month.
Is ettus Research LLC on a vacation?

-
Engin Karabulut, B.Sc.
Researcher

TUBITAK Marmara Research Center
Information Technologies Institute
41470 Gebze, Kocaeli/TURKIYE

Phone:+90 262 6772569  /2569
Fax  :+90 262 6463187





___
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] ettus usrp purchase problem

[Engin Karabulut]

we have sent a purchase order to ettus sales mail([EMAIL PROTECTED]) in order 
to
purchase a usrp hardware. But neither this mail nor matt's mail respond to 
me.
I have to purchase until december 15, because our purchase department won't 
work
after this date for a month.
Is ettus Research LLC on a vacation?

-
Engin Karabulut, B.Sc.
Researcher

TUBITAK Marmara Research Center
Information Technologies Institute
41470 Gebze, Kocaeli/TURKIYE

Phone:+90 262 6772569  /2569
Fax  :+90 262 6463187





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Ideas for improved FM reception

[Daniel Povey]

Guys [+girls?],
I'm new to the list.  I joined because I do research in signal processing
(speech recognition) and I have the idea
that it ought to be possible to use statistical signal processing to get
much better FM radio reception than a normal tuner.
I basically want to process the quadrature output (the 2 signals that you
get out after multiplying by sin + cos and
lopass filtering) in a different way, not just doing atan but doing a bunch
of predictive modeling at that stage, assuming
the signal is a mix of multiple stations + noise, and trying to separate the
signals out.
I want to ask this list two things:
(1) is anyone aware of anyone having tried something like this in the past
(or know what search
terms I might use to find this out), and
(2)  Could anyone give me to work with, the sampled output at the quadrature
stage (I assume this would be something
like 2 synchronized .wav or a stereo .wav file (does it support stereo?),
sampled at quite a high frequency).
Dan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[Brian Padalino]

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.  The goal is a development platform, and by choosing a
> solution dependent on GMSK, I essentially lock all MAC development in to
> using GMSK.  Is there a solution independent of the PHY layer?  I
> suppose I'm still not sure :)

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 manipulations.  OFDM would require
different processing in general.

> If some mechanism could be built in the FPGA that was highly
> reconfigurable, that would be fine... but it seems to be boiling down to
> different techniques per-modulation.

Not really an option for the USRP as it currently is due to the lack
of hardware multipliers.  Maybe more of an option for the USRP2.

On a side note, you should not feel bad about making something that
considers a trade-off in the realm of software defined radio.  You are
giving up (slight) PHY layer flexibility for much improved latency.
We're still using an antenna.  We're still using a super heterodyne
receiver.  Some things just can't be software and are limitations -
working around them is fine.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[George Nychis]

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 the GMSK as a simple PSK that only shifts 90
degrees for each transition.  No new multipliers should be required,
but memory will be needed for coefficients and samples.

How many bits is your address and how many bits is your frame sync?



Here's the thing, I don't want the solution to be dependent on the 
physical layer.  The goal is a development platform, and by choosing a 
solution dependent on GMSK, I essentially lock all MAC development in to 
using GMSK.  Is there a solution independent of the PHY layer?  I 
suppose I'm still not sure :)


If some mechanism could be built in the FPGA that was highly 
reconfigurable, that would be fine... but it seems to be boiling down to 
different techniques per-modulation.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[Brian Padalino]

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.

> 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 does ;)), I can detect incoming
>   frames without using the PHY 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.

> Let's say that a simple requirement is this: the frame format must have
> the destination address directly after the framing sequence.  Therefore
> I could use the matched filter to detect incoming frames to my address
> in the FPGA using a single sequence, without the turnaround time to the
> host.
>
> By doing this, I could generate ACKs much faster by storing
> pre-modulated data in the FPGA which is triggered.

You can accomplish this by using some simple sign manipulation/zero
insertion and treating the GMSK as a simple PSK that only shifts 90
degrees for each transition.  No new multipliers should be required,
but memory will be needed for coefficients and samples.

How many bits is your address and how many bits is your frame sync?

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] RFX400 C++ Driver

[TGV]

Hi everyone, 

I was able to successfully translate the RFX400 drivers in C++. 
There are some minor differences with the python code, but the class
structure is the same.  It would be easy to use this code for the others RFX
boards. Everything is documented with DOxygen. 

Unfortunately, I didn't test every function, just the ones I needed for my
application.

The code is probably not ready for official publication, but could really be
useful for an official publication in the near future.

Maxime Lepage
Université de Sherbrooke
-- 
View this message in context: 
http://www.nabble.com/RFX400-C%2B%2B-Driver-tf4944831.html#a14156544
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] in-band signaling & dependent packets (i.e., ACK generation)

[George Nychis]

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 does ;)), I can detect incoming 
 frames without using the PHY layer.


Let's say that a simple requirement is this: the frame format must have 
the destination address directly after the framing sequence.  Therefore 
I could use the matched filter to detect incoming frames to my address 
in the FPGA using a single sequence, without the turnaround time to the 
host.


By doing this, I could generate ACKs much faster by storing 
pre-modulated data in the FPGA which is triggered.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[George Nychis]

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* of what I want to overcome: latency between the USRP 
and host when ACK'ing a DATA frame in _any_ CSMA type protocol.


The frames I was transmitting are home-made frames that just so happen 
to use the same sync bits as the GNU Radio GMSK frames.  It's not really 
important, but the pattern I am looking for is the start of frame in 
sample space.


The "in sample space" is what's important, because I can obviously find 
the framing bit sequence by decoding the samples using the PHY layer... 
but this incurs the latency over the bus.  What I'm trying to do is 
detect the start of frame sequence without using the PHY layer to avoid 
this latency.


So as a first experiment I would mark what samples were needed to 
actually decode the frame bits, and was trying to see if I could pattern 
match these raw samples.  If there was a high correlation between the 
samples, I could simply implement some functionality in the FPGA to look 
for this pattern.  This would hopefully be independent of the PHY layer 
used.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[Brian Padalino]

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 correlation in the raw samples by calculating the
> correlation coefficient.  So, raw sample pattern matching does not seem
> quite possible.

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.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[George Nychis]

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 correlation in the raw samples by calculating the 
correlation coefficient.  So, raw sample pattern matching does not seem 
quite possible.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What is the right command to install wxPython on the Cygwin

[Brian Padalino]

On Dec 4, 2007 10:21 AM, JackyYang <[EMAIL PROTECTED]> wrote:
> Hi Sir:
>
> In the http://gnuradio.org/trac/wiki/wxPythonCygwin step9 : patch
> -p0 –b –I config.patch, I found the config.py at the
> /usr/src/wxPython-src-2.8.1.1/wxPython.  But, I gat "patch: *** Only garbage
> was found in the patch input.". What is the right command?

Be sure to click on the patch links at the bottom of the page, and
then use the download the original format link at the bottom of that
page.  You may be downloading the HTML page and NOT the patch itself.

Confirm this by using the "file" command and seeing if it comes back
with HTML or ASCII text.  ASCII text is what the patch file should be,
and NOT an HTML document.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio]What is the right command to install wxPython on the Cygwin

[JackyYang]

Dear Sir:

In the http://gnuradio.org/trac/wiki/wxPythonCygwin
  step9 : patch -p0 -b
-I config.patch, I found the config.py at the
/usr/src/wxPython-src-2.8.1.1/wxPython.  But, I gat "patch: *** Only garbage
was found in the patch input.". What is the right command?

 

The same question what is the right command in the step10?

 

Thanks!

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] What is the right command to install wxPython on the Cygwin

[JackyYang]

Hi Sir:

In the http://gnuradio.org/trac/wiki/wxPythonCygwin
  step9 : patch -p0 -b
-I config.patch, I found the config.py at the
/usr/src/wxPython-src-2.8.1.1/wxPython.  But, I gat "patch: *** Only garbage
was found in the patch input.". What is the right command?

 

The same question what is the right command in the step10?

 

Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio