Re: [Discuss-gnuradio] 802.11 Question

[Steve Glass]

Thanks Nick,

I actually want to generate ACKs at the USRP and then only for some frames.
Using a pair of real 802.11 cards I can increase the ACKTimeout and generate
the ACKs in software at the receiving WNIC but it's a little yukky.

If the USRP will work then its my preferred option.

Steve

On 6/7/07, jafa <[EMAIL PROTECTED]> wrote:


Steve Glass wrote:
> I'm considering using the USRP together with the 802.11 stack to
> prototype some 802.11 MAC layer changes. I'm sending from an 11b card
> at the base rate to my USRP/RFX2400.
>
> One shortcoming at present is that the code doesn't generate ACKs for
> received frames. There are quite strict timing requirements for ACK
> generation: for 11b at the base rate the ACK should be sent within a
> period measured in microseconds. I can increase the ACKTimeout but
> apparently there's a hard limit in my 802.11 equipment at 746us beyond
> which I will incur a rentransmission.
>
> I'm prepared to wade into the code but its a fool's errand if  the
> latencies will be too high to ACK within a few hundred microseconds.
> I'm worried that the block latencies and USB round-trip delay would
> seem to make this impossible. If anyone here can give me an informed
> opinion then I'll be really happy. So, does anyone know if it is it
> possible to generate an ACK within 700us or so of receiving a data
frame?
Hi Steve,

One trick for testing if you can't get the latency down - use a second
802.11b radio card and use the same MAC address in your gnuradio
implementation.

The 802.11b radio will automatically ACK every packet for its MAC address.

If the gnuradio based MAC has the same MAC address then you can then use
the gnuradio for transmission and reception of real data without needing
to transmit ACK packets.

The catch - if the gnuradio misses a packet you don't have the option of
not acking so it is sent again.

Nick



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





--
The day Microsoft sells something that doesn't suck is the day they start
selling vacuum cleaners.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio: Real newbie question

[keval]

Hey.
Thanks for the help - that explains why nothing happens when I type
./gnuradio.
Clearly, I need more help on this project than I originally thought.  Have
you found any particularly good websites on this app?
Many thanks,
Kevin




bellzii wrote:
> 
> hey kevin, 
> 
> I too am new to gnuradio but ive started learning few things and even
> start running examples on the usrp and soon i will do my own model, now
> concerning ur question ,theres actually no program called gnuradio , its
> just a signal processing package , all you have to do is write or run
> python program , and thats it!!
> 
> open ur terminal and in the gnuradio-examples --> python--> usrp directory
>  then ./usrp.osciloscope
> 
> im not very sure if i have dropped a directory cuz im not on linux now to
> check , but i hope this helps ;-)
> 
> 
> 
> 
> keval wrote:
>> 
>> Greetings.
>> OK - I've installed all the required libraries, dependencies, etc.  It
>> compiles and checks out just like it's supposed to.  Now: the Big
>> Question:  how do I start GNU Radio?  (I'm running Ubuntu (Fiesty Fawn)).  
>> Yes, I realize that this is a really, really basic question, but it's
>> nearly midnight and I'm just too tired to figure this out on my own.
>> Many thanks,
>> Kevin
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/GNU-Radio%3A-Real-newbie-question-tf3855589.html#a11001508
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] 802.11 Question

[jafa]

Steve Glass wrote:
I'm considering using the USRP together with the 802.11 stack to 
prototype some 802.11 MAC layer changes. I'm sending from an 11b card 
at the base rate to my USRP/RFX2400.


One shortcoming at present is that the code doesn't generate ACKs for 
received frames. There are quite strict timing requirements for ACK 
generation: for 11b at the base rate the ACK should be sent within a 
period measured in microseconds. I can increase the ACKTimeout but 
apparently there's a hard limit in my 802.11 equipment at 746us beyond 
which I will incur a rentransmission.


I'm prepared to wade into the code but its a fool's errand if  the 
latencies will be too high to ACK within a few hundred microseconds. 
I'm worried that the block latencies and USB round-trip delay would 
seem to make this impossible. If anyone here can give me an informed 
opinion then I'll be really happy. So, does anyone know if it is it 
possible to generate an ACK within 700us or so of receiving a data frame?

Hi Steve,

One trick for testing if you can't get the latency down - use a second 
802.11b radio card and use the same MAC address in your gnuradio 
implementation.


The 802.11b radio will automatically ACK every packet for its MAC address.

If the gnuradio based MAC has the same MAC address then you can then use 
the gnuradio for transmission and reception of real data without needing 
to transmit ACK packets.


The catch - if the gnuradio misses a packet you don't have the option of 
not acking so it is sent again.


Nick



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

[Discuss-gnuradio] 802.11 Question

[Steve Glass]

Hi,

I'm considering using the USRP together with the 802.11 stack to prototype
some 802.11 MAC layer changes. I'm sending from an 11b card at the base rate
to my USRP/RFX2400.

One shortcoming at present is that the code doesn't generate ACKs for
received frames. There are quite strict timing requirements for ACK
generation: for 11b at the base rate the ACK should be sent within a period
measured in microseconds. I can increase the ACKTimeout but apparently
there's a hard limit in my 802.11 equipment at 746us beyond which I will
incur a rentransmission.

I'm prepared to wade into the code but its a fool's errand if  the latencies
will be too high to ACK within a few hundred microseconds. I'm worried that
the block latencies and USB round-trip delay would seem to make this
impossible. If anyone here can give me an informed opinion then I'll be
really happy. So, does anyone know if it is it possible to generate an ACK
within 700us or so of receiving a data frame?

Kind regards

Steve

--
The day Microsoft sells something that doesn't suck is the day they start
selling vacuum cleaners.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VIA USB-2 combo card card, not working on linux for usrp

[Matt Ettus]

> Or does anybody have a suggestion of an USB-2 addon card for a notebook 
> (pccard) that works with the USRP.
>   

Jim Perkins recently told me the following:

I recently tested an inexpensive Zonet USB 2.0 add-on card. It has
the Via VT6212L chipset.  The Via based card worked very well.  The
benchmark_usb.py test returned OK for all speeds including 32 MB/s.

Matt



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

Re: [Discuss-gnuradio] software implementation of GSM

[Joshua Lackey]

(Moving discuss-gnuradio to bcc.)

You can tell when it's working because of all the error messages you
get.

[EMAIL PROTECTED]:~/src/gsm/gssm-v0.1/src/python$ ./file_gssm.py 
~/src/gsm/signal/signal.data 
>>> gr_fir_fff: using SSE
error: PCH, AGCH (0, 36)
error: SACCH8 (0, 36)
error: PCH, AGCH (0, 36)
error: SACCH8 (0, 36)
error: PCH, AGCH (0, 36)
error: SACCH8 (0, 36)
error: PCH, AGCH (0, 12)
error: SDCCH8 (0, 12)
error: PCH, AGCH (0, 46)
error: PCH, AGCH (0, 36)
error: SACCH8 (0, 36)
error: PCH, AGCH (0, 22)
error: PCH, AGCH (0, 26)
error: PCH, AGCH (0, 36)
[...]


So even if nothing is appearing in Wireshark, you should still be able
to tell if the radio demod path is working.

You can also add a few debug printf()'s in the code to see how far
you're getting.  Try adding a 'printf("fc found!\n");' at line 316 in
gssm_sink.cc and a 'printf("sch found!\n");' at line 360.  (It will be
line 361 if you first add line 316.)

Then you'll be able to see when you lock on the frequency correction
channel and the synchronization channel.


Quoting Eng. Firas ([EMAIL PROTECTED]):
> 
> Hi Joshua,
> 
> I followed installation instruction with almost no errors. But, when running
> Wireshark, I get nothing displayed with the GSM interface. My BTS signal is
> very high, and I located the offset of the frequency correction burst (which
> is by the way almost the same as your default one). Any suggested checking
> point ?
> 
> Firas,


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

[Discuss-gnuradio] VIA USB-2 combo card card, not working on linux for usrp

[Martin Dvh]

Hi all,
I am using a combo pccard (USB-2 and firewire) with VIA chipset to get USB-2 on 
my laptop.

But using linux I can't get it to work.
I get usrp overruns, (uOuOuO) even with decimation factors of 200 when using 
usrp_rx_cfile.py
This is only 320 ksamples/sec

with top I see that the CPU is 80 % idle, so that is not the problem.

When running benchmark_usb.py I get slightly better performance, 2 MB/sec works 
and 4 MB/sec works sometimes, all above fail.

I don't know why benchmark_usb works better then usrp_rx_cfile.

When I run usrp_wfm_rcv_nogui.py I get garbled sound and uO and aU, but this is 
logical. The script doesn't get enough data from the USRP.

On windows usrp_rx_cfile.py just works fine with the same usb-2 card. (This is 
a much older gnuradio/usrp release though)

Does anybody have a clue, what is wrong here.

I tried both kernel 2.6.18 and 2.6.20. I also tried noacpi acpi=off apm=off as 
kernel-boot param.

Or does anybody have a suggestion of an USB-2 addon card for a notebook 
(pccard) that works with the USRP.

Greetings,
Martin



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

Re: [Discuss-gnuradio] CPM timing recovery

[Tim Meehan]

The point where theory meets practice is what makes engineering fun.

If when you say "Nothing that modulates data has constant envelope"

you mean it in the same sense that passbands are never truly flat and bit
error rates are never 0, then I agree with you.   But I claim that a
received CPM signal has constant envelope to within some small tollerence,
and I would argue 1% type numbers for magnitude variation are not out of the
question.

Tim

On 6/6/07, Dan Halperin <[EMAIL PROTECTED]> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nothing that modulates data has constant envelope. Plot the amplitude of
a BPSK or GMSK signal (after transmission, not simulation) sometime.

- -Dan

Achilleas Anastasopoulos wrote:
> Bob,
>
> this is not correct.
>
> The CPM signal is by definition constant envelope.
> It is defined as
> s(t)=exp(j phi(t))
> where
> phi(t)= 2 pi int_0^t f(t') dt'
> where
> f(t)= h sum_k a_k p(t-kT).
> Selecting the approprate pulse shape p(t) shapes the spectrum of CPM,
> but regardless of the selection it has continuous phase
> (not abrupt transitions) as the name suggests ;-) and constant envelope.
> Thus the method you suggested (looking at the envelope variations)
> will not work.
>
> Achilleas
>
>
> ==
> Since the signal will not really have infinite bandwidth (instantaneous
> transitions from one state to the next),  the envelope will not be of
> constant modulus.  The signal will be amplitude modulated with a
> component due to the data transitions.  Looking at the modulus or
> modulus squared will reveal a line in the fft due to this amplitude
> modulation.
>
> Bob
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZue7y9GYuuMoUJ4RAtJ0AJwNEeom3VXahGVfdCYX6Sw536RtSACgw5vF
ntNgOm89dQPZkBHQyHTh6zk=
=eu2i
-END PGP SIGNATURE-


___
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

Re: [Discuss-gnuradio] software implementation of GSM

[Eng. Firas]

Hi Joshua,

I followed installation instruction with almost no errors. But, when running
Wireshark, I get nothing displayed with the GSM interface. My BTS signal is
very high, and I located the offset of the frequency correction burst (which
is by the way almost the same as your default one). Any suggested checking
point ?

Firas,


Joshua Lackey-2 wrote:
> 
> gssm-v0.1
> 
> Groupe Special (Software) Mobile
> 
>  or
> 
> The Global Software System for Mobile communications
> 
> ---
> 
> SUMMARY
> 
> Okay, calling gssm "The Global Software System for Mobile
> communications" is a bit of a stretch as all it does is monitor GSM
> control channels.
> 
> What this package does is use the USRP and various daughterboards to
> capture live data, GNU Radio and custom modules to demodulate and decode
> the GSM packets, and then Wireshark to display the data.
> 
> 
>   Get it here:http://thre.at/gsm
>   Install instructions:   http://thre.at/gsm/index.html#install.
>   Talk about it here: [EMAIL PROTECTED]
>   More here:  http://wiki.thc.org/gsm.
> 
> ---
> 
> WHAT
> 
> This package monitors GSM base station control channels. It uses the
> USRP and various daughterboards to capture live data, GNU Radio and
> custom modules to demodulate and decode the GSM packets, and then
> Wireshark to display the data.
> 
> This version of gssm decodes most of the control channels. The control
> channels contain the information necessary for a mobile to communicate
> with a base station. The control channels gssm currently decodes are:
> 
>   FCCHThe frequency correction channel.
>   SCH The synchronization channel.
>   BCCHThe broadcast control channel.
>   PCH The paging channel. Downlink only, used to page mobiles.
>   AGCHThe access grant channel. Downlink only, used to
>   allocate an SDCCH or directly a TCH.
>   SACCH   Slow associated control channel.
>   SDCCH   Stand-alone dedicated control channel.
> 
> gssm displays the decoded data using Wireshark. Not only does this give
> us a very nice graphical front end to examine the dissected packets, but
> Wireshark already has quite a bit of code to dissect GSM data.
> Unfortunately, the current implementation of Wireshark does not dissect
> packets unique to the wireless interface. Up to now, there was no reason
> to include code to dissect these packets. I include a patch for
> wireshark-0.99.5 which adds partial Um packet dissection capability
> and a new custom ethertype to interface with the USRP.
> 
> While gssm has basic functionality now, it really is alpha-quality
> software and there are a number of enhancements which must be made
> before it becomes truly useful.
> 
>   1. The Mueller and Muller clock recovery method doesn't always
>   handle the quarter-bits present in a GSM burst. A more reliable
>   method must be implemented. Until then, this software will
>   suffer from a large number of receive errors even with a high
>   signal-to-noise ratio.
> 
>   2. Wireshark dissects most GSM packets except those specific to
>   the Um interface, the wireless interface between the mobile and
>   the BTS, the Base Transciever Station.
> 
>   a. I've only implemented a small portion of the Um
>   interface. Much more work must be done to complete this.
> 
>   b. Only the Bbis frame type is implemented. When packets
>   arrive in Wireshark which are "malformed" or with
>   strange protocol descriptors, it is because they were
>   sent using some other frame type.
> 
>   c. The interface between gssm and Wireshark is extremely
>   hacky, to say the least. It would be nice to eventually
>   standardize a GNU Radio interface for Wireshark. I also
>   want to clean up my Um interface and submit that there
>   as well.
> 
>   3. You need to find your local GSM tower by hand. Once you've
>   found it, you need to edit the python script and enter the
>   information by hand. It would be very nice if this information
>   were automatically generated.
> 
>   4. The code is designed to support all frequency bands but I
>   haven't implemented anything but U.S. support.
> 
>   5. This code is receive-only and currently can only monitor
>   tower to mobile transmissions.
> 
>   6. Lots more.
> 
> ---
> 
> WHERE
> 
> This code is being adopted by the GSM Scanner Project and any updates to
> this code will be found there. Questions and suggestions can certainly
> be sent to me, but they also should be directed to the mailing list --
> [EMAIL PROTECTED] Also, check out the wiki at
> http://wiki.thc.org/gsm.
> 
> The current version of this code can be found here:
> http://thre.at/gsm/gsm-v0.1.tar.bz2. Updates and bug-fixes will be
> located at the GSM Scanner Project, http://wiki.thc.org.

[Discuss-gnuradio] A little beginner-GUI

[Ruben Undheim]

I have put together a little beginner GUI, which can demodulate FM, AM and 
SSB from files and from the USRP by pointing at a FFT-display. Since I am 
quite new myself, I did this as a "beginner"-project. I just wondered if 
some other of you guys had made something similar, and could post your code?


You can find my code at:
http://folk.ntnu.no/undheim/sdr/gnuradio-control-gui-0.02.tar.gz

A screenshot can be found at:
http://folk.ntnu.no/undheim/sdr/usrfft.jpg

The code is not very clean.. but it seems to work at least here. Bug-reports 
would be nice to get!



Ruben

_
MSN Spaces http://spaces.msn.com/?mkt=nb-no Vis hvem du er og hva du vil



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

Re: [Discuss-gnuradio] Make error [svn revision 5708]

[Tarun Tiwari]

Trond Danielsen wrote:



I just pulled a fresh copy from svn (rev.5708), ran ./bootstrap;
./configure; make. No problems so far. I recommend that you run
./bootstrap and ./configure again after pulling from svn. This ensures
that the generated Makefiles are updated according to the svn changes.



The real issue is that there are "stale" .d files in
gnuradio-core/src/lib/swig.  These files have lists of dependencies in
them, and one of the .i files listed has been deleted when updating svn.
You can't just delete the .d files because they themselves are listed as
a dependency in the Makefile.



The most precise way to update your working directory to build again is
to edit these .d files and remove the offending file name.  You can also
delete all the .d files in this directory, and let the build repopulate
them, by re-running ./configure.  One of the last things ./configure
does is to "touch" these files, and if they don't exist, they get created.


I used this method but still got the error as followed:
gnuradio_swig_py_general.cc:43663: error: 'gr_dpll_ff' was not declared in
this scope


The sledgehammer approach is to do a 'make distclean' followed by a full
rebuild.


This was the only option left to me and it worked, but took lot of time :-|


The way the swig dependencies are tracked is broken here, but works well
for everything else, falling over only when the repository is updated
and a .i file that was previously there is removed.



Patches welcome :-)



--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com 


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

Re: [Discuss-gnuradio] CPM timing recovery

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nothing that modulates data has constant envelope. Plot the amplitude of
a BPSK or GMSK signal (after transmission, not simulation) sometime.

- -Dan

Achilleas Anastasopoulos wrote:
> Bob,
> 
> this is not correct.
> 
> The CPM signal is by definition constant envelope.
> It is defined as
> s(t)=exp(j phi(t))
> where
> phi(t)= 2 pi int_0^t f(t') dt'
> where
> f(t)= h sum_k a_k p(t-kT).
> Selecting the approprate pulse shape p(t) shapes the spectrum of CPM,
> but regardless of the selection it has continuous phase
> (not abrupt transitions) as the name suggests ;-) and constant envelope.
> Thus the method you suggested (looking at the envelope variations)
> will not work.
> 
> Achilleas
> 
> 
> ==
> Since the signal will not really have infinite bandwidth (instantaneous
> transitions from one state to the next),  the envelope will not be of
> constant modulus.  The signal will be amplitude modulated with a
> component due to the data transitions.  Looking at the modulus or
> modulus squared will reveal a line in the fft due to this amplitude
> modulation.
> 
> Bob
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZue7y9GYuuMoUJ4RAtJ0AJwNEeom3VXahGVfdCYX6Sw536RtSACgw5vF
ntNgOm89dQPZkBHQyHTh6zk=
=eu2i
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] Make error [svn revision 5708]

[Johnathan Corgan]

Trond Danielsen wrote:

> I just pulled a fresh copy from svn (rev.5708), ran ./bootstrap;
> ./configure; make. No problems so far. I recommend that you run
> ./bootstrap and ./configure again after pulling from svn. This ensures
> that the generated Makefiles are updated according to the svn changes.

The real issue is that there are "stale" .d files in
gnuradio-core/src/lib/swig.  These files have lists of dependencies in
them, and one of the .i files listed has been deleted when updating svn.
You can't just delete the .d files because they themselves are listed as
a dependency in the Makefile.

The most precise way to update your working directory to build again is
to edit these .d files and remove the offending file name.  You can also
delete all the .d files in this directory, and let the build repopulate
them, by re-running ./configure.  One of the last things ./configure
does is to "touch" these files, and if they don't exist, they get created.

The sledgehammer approach is to do a 'make distclean' followed by a full
rebuild.

The way the swig dependencies are tracked is broken here, but works well
for everything else, falling over only when the repository is updated
and a .i file that was previously there is removed.

Patches welcome :-)

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] GNU Radio: Real newbie question

[bellzii]

hey kevin, 

I too am new to gnuradio but ive started learning few things and even start
running examples on the usrp and soon i will do my own model, now concerning
ur question ,theres actually no program called gnuradio , its just a signal
processing package , all you have to do is write or run python program , and
thats it!!

open ur terminal and in the gnuradio-examples --> python--> usrp directory
 then ./usrp.osciloscope

im not very sure if i have dropped a directory cuz im not on linux now to
check , but i hope this helps ;-)




keval wrote:
> 
> Greetings.
> OK - I've installed all the required libraries, dependencies, etc.  It
> compiles and checks out just like it's supposed to.  Now: the Big
> Question:  how do I start GNU Radio?  (I'm running Ubuntu (Fiesty Fawn)).  
> Yes, I realize that this is a really, really basic question, but it's
> nearly midnight and I'm just too tired to figure this out on my own.
> Many thanks,
> Kevin
> 

-- 
View this message in context: 
http://www.nabble.com/GNU-Radio%3A-Real-newbie-question-tf3855589.html#a10989927
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] CPM timing recovery

[Achilleas Anastasopoulos]

Bob,

this is not correct.

The CPM signal is by definition constant envelope.
It is defined as
s(t)=exp(j phi(t))
where
phi(t)= 2 pi int_0^t f(t') dt'
where
f(t)= h sum_k a_k p(t-kT).
Selecting the approprate pulse shape p(t) shapes the spectrum of CPM,
but regardless of the selection it has continuous phase
(not abrupt transitions) as the name suggests ;-) and constant envelope.
Thus the method you suggested (looking at the envelope variations)
will not work.

Achilleas


==
Since the signal will not really have infinite bandwidth (instantaneous
transitions from one state to the next),  the envelope will not be of
constant modulus.  The signal will be amplitude modulated with a
component due to the data transitions.  Looking at the modulus or
modulus squared will reveal a line in the fft due to this amplitude
modulation.

Bob


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

Re: [Discuss-gnuradio] A rfx2400 is down, which chip on the borad is broken?

[Lin HUANG]

I'd like to report to all of you our investigation results. At least, the TX
side works now. But for the RX side, I think it is absolutely broken and I
give up to repair it.
I changed the resistors R40, R42, R46, R130, R132, R136 to be 1k ohms. This
prevents the RX side influencing the TX side. And I connected the 6V power
of TX side with the power pin of the control part (U203), because the power
of RX is not normal. Then the TX side can work.

Thanks a lot for Ettus's help.~
HUANG Lin


2007/5/30, Lin HUANG <[EMAIL PROTECTED]>:


 I continued checking these broken boards recent days. I found for the TX
> side, the graph stops as soon as it starts. It seems the daughter board
> gives some signal to stop the motherboard to load data from PC. I read the
> .sch file in the subversion repository and the defination of the interface
> between db and mb.
>

IOUTN_B IOUTP_B IOUTP_A IOUTN_A    the analog IF signal   mb-->db
clock  the db is synchronous with mb   mb-->db
I2C_A0 I2C_A1  TX/RX RX1/RX switch control signal  mb-->db
SCLK SDA  R/W interface to E2PROM  mb<-->db
IO0~IO15  for debug usage. mb<-->db

Which pin will give a wrong signal to motherboard and disable the board?
IO? We never used u_write_oe. So it may be as a input?

Thanks for Eric and Nikhil's help before. Hope you are continously
interested in my bug investigation. Thank you. :)

HUANG Lin



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

Re: [Discuss-gnuradio] Make error [svn revision 5708]

[Trond Danielsen]

2007/6/6, Tarun Tiwari <[EMAIL PROTECTED]>:

Hi,

Today I update the gnuradio from svn, and received following error in make:

make[5]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/swig'
make[5]: *** No rule to make target
`../../../../gnuradio-core/src/lib/general/gr_dpll_ff.i',
needed by `gnuradio_swig_py_general.cc'.  Stop.

Then, I edited the Makefile.am in
../../../../gnuradio-core/src/lib/general/ and added
gr_dpll_ff.{cc,h,i} but I got following error :

make[6]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/general'
make[6]: *** No rule to make target `gr_dpll_ff.cc', needed by
`gr_dpll_ff.lo'.  Stop.

Can somebody check the Makefile as I am not able to identify the problem?

Thanks in advance.

Regards,
Tarun
UT Dallas


I just pulled a fresh copy from svn (rev.5708), ran ./bootstrap;
./configure; make. No problems so far. I recommend that you run
./bootstrap and ./configure again after pulling from svn. This ensures
that the generated Makefiles are updated according to the svn changes.

--
Trond Danielsen


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

[Discuss-gnuradio] Make error [svn revision 5708]

[Tarun Tiwari]

Hi,

Today I update the gnuradio from svn, and received following error in make:

make[5]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/swig'
make[5]: *** No rule to make target
`../../../../gnuradio-core/src/lib/general/gr_dpll_ff.i', needed by
`gnuradio_swig_py_general.cc'.  Stop.

Then, I edited the Makefile.am in ../../../../gnuradio-core/src/lib/general/
and added gr_dpll_ff.{cc,h,i} but I got following error :

make[6]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/general'
make[6]: *** No rule to make target `gr_dpll_ff.cc', needed by
`gr_dpll_ff.lo'.  Stop.

Can somebody check the Makefile as I am not able to identify the problem?

Thanks in advance.

Regards,
Tarun
UT Dallas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio