On Sun, Feb 6, 2011 at 1:34 PM, Varun Krishnamurthy <
varun.sumkr...@gmail.com> wrote:
> Hi ,
>
>
> I am new to GNU Radio and am facing difficulties in implementing DQPSK
> modulation on Gnu Radio Companion. The system works fine , but for one small
> glitch. The DQPSK modulator/demodulator's inpu
On Wed, Jan 12, 2011 at 3:22 PM, Michael Dickens wrote:
> On Jan 12, 2011, at 2:56 PM, Moeller wrote:
> > On 12.01.2011 14:25, Michael Dickens wrote:
> >> the CPU). I think that if a GPU can be used, it will be most effective
> in things like filterbanks, or when searching for packets (via their
On Wed, Jan 12, 2011 at 2:44 AM, Moeller wrote:
> On 11.01.2011 23:13, Andrew Hofmaier wrote:
> > I've begun to look into accelerating GNURadio applications with Nvidia
> CUDA GPU's
> > and have scanned through the archives of the discussion list. I had two
> > questions on the topic:
> >
> > 1.
> Think of the on/off part as a control stream consisting of 1's and
> 0's. Generate the control stream, and multiple the control stream by
> the carrier stream.
>
> Don't try to start and stop the graph or anything like that from
> python.
>
> You can probably generate the control stream with a
>
On Thu, Nov 18, 2010 at 6:34 AM, Songsong Gee wrote:
> I am now building a flow graph for ASK modulation,during the test,
>
> Here is my flow graph,
> http://picasaweb.google.com/lh/photo/-4xnI_UgFeSNENH3UGHgxw?feat=directlink
>
> And this is the result plot,
> http://picasaweb.google.com/lh/photo
On Wed, Nov 17, 2010 at 2:45 PM, Marcus D. Leech wrote:
> On 11/17/2010 12:43 PM, Marcus D. Leech wrote:
>
>>
>>
>> What I'm seeing is that the magnitudes (as seen in the number sink) coming
>> off the source, even with roughly 75dB of gain ahead
>> are roughly 0.002 to 0.003 when I'm using 400
On Wed, Nov 17, 2010 at 3:41 AM, Songsong Gee wrote:
> I use two USRPs. One sends a sinusoidal signal, and the other receives it.
>
> A flow graph and a result are here
> flow graph:
> http://lh5.ggpht.com/_byQV8nmc5FA/TOOTX9ReSYI/AQk/hWJ9Kf5GcAA/s800/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7-1
be i can implement in a
> different way , but i cant as imy system
> has become bigger now.Please guide me if you have any means to solve my
> problem
> i want to see "line" variable to show me the tuned frequency the moment i
> tune to that frequency.
>
> Than
On Sat, Nov 13, 2010 at 4:19 AM, ton ph wrote:
> Hi everyone,
>As I was trying to tune usrp from my python thread, I am not able to use
> my thread to tune the USRP. I am trying to tune using my python function,
>
> def tune_usrp(ms,freq):
> print "Tuning to frequency : "+str(freq)
>
>
> The second image shows the plot of the two real components of the same 128
> samples.
> The phase shift is so large it is visible in the plot. I
> I noticed that the tuned frequency is about 12 kHz off target, but this is
> within the expected spec. of the system.
>
>
> http://old.nabble.com/f
I just did a fresh git checkout and install of UHD as described here:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
http://www.ettus.com/uhd_docs/manual/html/build.html
Everything appears to go smoothly, but ./uhd_find_devices reports:
linux; GNU C++ version 4.4.4 20100630 (Red
On Mon, Nov 8, 2010 at 11:52 AM, Thomas H Kim wrote:
> Steven,
>
> Thank you very much for your email.
> I installed Fedora Core13 x86_64, instead of i386, which I installed on
> last Friday and it works now. But, I don't understand because i386 should
> work on 64bit machine (that was what I've
On Mon, Nov 8, 2010 at 7:59 AM, Martin Braun wrote:
>
> Even in an old version, this should not happen. However, if you do have
> an old version, I recommend upgrading to at least 3.3.0 and trying
> again. Once it works, you'll simply have much more fun (read:
> functionality) with a newer GNU Ra
On Thu, Nov 4, 2010 at 5:33 PM, Yan Nie wrote:
> Dear all,
>
> I am developing a transmitter on USRP1 with LFTX daughterboard. This
> transmitter sends a BPSK modulated Barker code sequence up-converting to a
> frequency ranging from 1MHz to 20MHz. I implemented the transmission of the
> whole se
On Tue, Nov 2, 2010 at 4:32 PM, Rachel Li wrote:
> Hi all:
>
> I have Tx and Rx on different machines. To measure the BER, I need to
> compare the a reference stream and the output stream of the demodulator.
>
> I suspect that my way to obtain the reference stream is wrong.
>
> Here is how I obta
Hi all-
I got a simple form of frequency hopping working without too much trouble,
by having a free-running flowgraph in thread A, while thread B periodically
retunes the flowgraph's USRP output. This seems to work fine.
Now, what are some techniques to use if I want to introduce dead time to the
Hi all-
Any estimate as to the readiness level of the UHD driver? (if open-source
has such a concept...)
Back in April they were called "pre-alpha". How are things progressing? Do
you recommend use of it yet to people whose day-job would (lamentably)
prefer they be productive? :)
As a checklist,
The 100mW transmit spec, is that at +0dB gain, or at +25dB gain (max)?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Oct 14, 2010 at 12:13 PM, Steven Clark wrote:
> Hi all-
>
> I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
> performed the clock synching described here:
> http://gnuradio.org/redmine/wiki/1/MultiUsrp
>
> I'm doing 4-channel receive,
On Wed, Oct 20, 2010 at 7:41 PM, Steven Clark wrote:
> On Thu, Oct 14, 2010 at 12:47 PM, Matt Ettus wrote:
>
>>
>> Probe R201 on all 4 WBX boards with an oscilloscope while running. One
>> side of the resistor is ground and the other side is the reference clock.
>&
; frequency and phase.
>
> Matt
>
>
> On 10/14/2010 09:13 AM, Steven Clark wrote:
>
>> Hi all-
>>
>> I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
>> performed the clock synching described here:
>> http://gnuradio.org/redmine/wi
Hi all-
I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
performed the clock synching described here:
http://gnuradio.org/redmine/wiki/1/MultiUsrp
I'm doing 4-channel receive, using a power splitter to send the same CW
signal into all 4 d'cards, and tuning them all identic
Hi-
Is it possible to receive simultaneously from 1 WBX card, and 1 BasicRX
card, on the same USRP1? Attempting this with GRC gives:
"Cannot compute dual mux when mixing quadrature and non-quadrature
subdevices"
I understand that the WBX is quadrature while the BasicRX is not, so this
should requ
On Thu, Jun 12, 2008 at 12:24 PM, Mihail L. Sichitiu <[EMAIL PROTECTED]> wrote:
>
> Hi there,
>
> I'm brand new at this GNU Radio thing, so please forgive me if my question
> has a "well-known" answer. I'd like to try out some performance tests on a
> few modulation schemes, so I need a clean band
On Wed, Jun 11, 2008 at 11:01 AM, Firas A. <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> New USRP Documentation (Whenever I become sick and stay at home, I use my
> time to write some GnuRadio documentation).
>
> I hope from Gnuradio experts to examine this document and send to me a
> corrected informati
>
> The latest patch and instructions on how to use it are given in the wiki at
> http://www.gnuradio.org/trac/wiki/CygwinInstallMain.
>
> Be sure to do the "./bootstrap" after applying the patch.
>
> With any luck, this should be the last release to have this problem.
>
> -- Don W.
>
Don-
Many t
On Fri, Jun 6, 2008 at 9:30 AM, Long, Jeffrey P. <[EMAIL PROTECTED]> wrote:
> Steven-
>
> Did you actually find that the decision threshold needs to be biased? I
> actually implemented the 2 bit differential detector on a custom asic
> that was targeted at streaming audio(in 2004) and during the
>
On Fri, Jun 6, 2008 at 8:56 AM, isaacgerg <[EMAIL PROTECTED]> wrote:
>
> Ive noticed that the papers you cited only take in "real" data and not
> "complex." Is this true? Is this true for your implementation?
>
> Isaac
I think they do in fact take in complex. How would one do a 90deg
phase shift
> On 6/6/08, Bob McGwier <[EMAIL PROTECTED]> wrote:
>>
>> This is not my professional experience. The sounding data is used to find
>> the channel and then the data symbols are soft detected through a "viterbi
>> equalizer" in every implementation I am aware of that is any good at all
>> with the
On Thu, Jun 5, 2008 at 5:28 PM, Gregory Maxwell <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 3:25 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> [snip]
>> It should be a
>> drop-in replacement for the existing demodulator in designs, except
>> t
I noticed that many gnuradio files (gmsk.py for example) contain an
unholy mix of spaces and tabs for indentation. Is there any easy way
to standardize our indentation? Many text editors can make it so
hitting tab creates 4 spaces instead of the tab character.
(I like 4 spaces per indent, what ab
>
> Steven,
>
> If you were to generate a patch that had your demodulator show up as a
> new demod called, say, gsm_demod_alt2 that hooked it into the existing
> framework with this new name, we could add it to the tree and it would
> get more testing without having to overwrite the known implemena
I've added a link to
http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
http://gnuradio.org/trac/wiki/OurUsers
Summary:
[...] offers an enhanced GMSK demodulator that I believe to be
superior to the GNURadio standard gmsk demodulator. It should be a
drop-in replacement for the existing
On Thu, Jun 5, 2008 at 7:45 AM, isaacgerg <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Concerning GSM GMSK demodulation, due to the ISI, I initially thought many
> folks were using the Viterbi algorithm on the waveform to demodulate it
> properly. After doing some lit review, I am finding that this is no
>
> It looks like you are missing a patch (attachment:"makefiles6975.patch,
> listed on the Cywin wiki page) needed to include the mblock library in the
> link of qa_inband_usrp_server.
>
> -- Don W.
>
Thanks for the reply. I did in fact try to apply both patches that are
mentioned on the page, bu
> I haven't found information for simple_framer/simple_correlator inputs and
> outputs and have no idea where my "ValueError: source and destination data
> sizes are different" problem comes from. Any hints would be appreciated!
>
> Thank you for your help!
>
> Irene
Make sure you know what type o
adio has a unpacked_to_packed block for this purpose.
On Tue, May 20, 2008 at 12:53 PM, irene159 <[EMAIL PROTECTED]> wrote:
>
>
> Steven Clark-2 wrote:
>>
>> This is not surprising. It is likely that you are getting some initial
>> garbage (non-standard-ascii characters) comi
This is not surprising. It is likely that you are getting some initial
garbage (non-standard-ascii characters) coming out, or that you have
some bit errors.
Don't open it in gedit. Try:
python
f = open('Resultat.txt')
d = f.read()
f.close()
print(len(d))
print(d)
(or if d is really long, print(d[:
Apologies for the necromancy, but I would like to help by adding an
item or two to the FAQ section. How do I get a trac account?
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
A certain daughtercard can support 0-70dB of gain, and the main-board
A/D chip can do 0-20dB of gain.
If I request 50dB of gain from software, how does this get distributed
between these two locations? Is one used preferentially over the
other?
___
Dis
On Sat, Mar 8, 2008 at 11:20 PM, Manav Rohil <[EMAIL PROTECTED]> wrote:
>
> I am getting segmentation fault with the following...
>
> src_data = (0xff,)
> src = gr.vector_source_b(src_data,False)
> #expected_results = (1,0,0,0,0,0,0,0)
> op = gr.packed_to_unpacked_bb(1, gr.GR_MS
On Tue, Mar 4, 2008 at 2:27 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> I like the use of the watcher thread in pkt.demod_pkts, and was
> wondering if I could use a similar technique in the following
> situation:
>
> Two disconnected subgraphs:
> msg_sourc
I like the use of the watcher thread in pkt.demod_pkts, and was
wondering if I could use a similar technique in the following
situation:
Two disconnected subgraphs:
msg_source_1 -> transform_blk_1 -> msg_sink_1
msg_source_2 -> modulator
The user places 'm'-byte messages in msg_source_1.
tr
No USRP, no problem. Here is an example of what you want (taken from
http://noether.uoregon.edu/~jl/gmsk/gmsk-test.py)
# Mix to IF
lo = gr.sig_source_c(sample_rate, gr.GR_SIN_WAVE, lo_freq,
1.0, 0)
mixer = gr.multiply_cc()
If you are using the USRP, it handles all the conversion to and from
carrier frequency. The data going across the USB bus is generally
complex baseband.
You instruct the USRP what the carrier frequency should be:
#Set freq
if not(usrp.tune(self.usrp_out, 0, self.out_dcard, tx_freq)
Has anybody had any luck using any form of Forward Error Correction in
GNU Radio in a streaming context?
I'm hoping to compare notes / techniques.
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/
> Your msg_source, which is a gr.message_source, is blocked, waiting for
> new messages to arrive. In order to allow the second block chain to
> exit, you need to send it a message that causes it to unblock. The
> flowgraph scheduler thread that is running this chain will then see
> the indication
On Jan 31, 2008 1:13 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 31, 2008 at 10:49:50AM -0500, Steven Clark wrote:
> > Pardon the bump. Maybe I should simplify the question:
> >
> > With the packet modulator, is it possible to run the packet payload
> &
Pardon the bump. Maybe I should simplify the question:
With the packet modulator, is it possible to run the packet payload
bits through any kind of flow-graph/block during the rx_callback?
On Jan 27, 2008 6:39 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> 'lo all.
>
> I woul
Should Rx1 be a vector_source_f rather than a vector_sink_f?
-Steven
On Jan 29, 2008 10:17 PM, Jonas <[EMAIL PROTECTED]> wrote:
> Hi everyone!
>
> I have this problem with using gr_float_to_complex. I wanted to connect two
> sptr types wherein one contains floats while the other is an sptr type o
I asked the same thing a year or so ago, didn't get much of an answer.
AFAIK, there are no software hooks for the digital I/O pins. What we
ended up doing was editing the verilog such that the sign of the real
component sent to the BasicTX dboard came out on 1 I/O pin, and the
sign of the imag com
'lo all.
I would like to place code in the rx_callback of the packet mod
architecture that takes each received payload and runs it though
gr.trellis's viterbi decoder.
Should this be possible?
It seems like I'd have to set up, run, and tear-down a flowgraph or
top-block in the duration of the cal
> You might be able to run unpacked_to_packed followed by
> packed_to_unpacked to get what you want. It's ugly, but you don't
> have to write any code ;)
>
> pack = gr.unpacked_to_packed_ss(2, gr.GR_MSB_FIRST)
> unpack = gr.packed_to_unpacked_ss(1, gr.GR_MSB_FIRST)
>
> Eric
>
Aha! Shame on me
0, 1)
rather than:
(1,0,1,1,0,1)
*bang head on keyboard in search of enlightenment*
On Jan 10, 2008 4:51 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 04:43:17PM -0500, Steven Clark wrote:
> > Hey folks-
> >
> > Let's say I have a str
Hey folks-
Let's say I have a stream of shorts whose values are one of [0,1,2,3] (in
other words, the bottom 2 bits are active). I want to split these bits, so
that:
[2,3,3,1,0] -> [1,0,1,1,1,1,0,1,0,0], etc.
What block(s) can help me achieve this?
___
This article might be helpful. It's targeted at matlab, but easily
transferable to python.
http://www.transcrypt.com/resources/all/files/19388/_fn/bit-error-rate_simulation_using_matlab.pdf
On Nov 10, 2007 11:15 AM, Meenaktchi Venkatachalam <[EMAIL PROTECTED]>
wrote:
>
>
> On Nov 9, 2007 11:46 AM
I'm just trying to gather information about what types of FEC are currently
available in GNURadio.
A quick scan of directories shows me:
Reed-Solomon (no changes in 4 years)
Trellis / Viterbi (created by Achilleas?)
Are there any others? (could we maybe reorganize them into a unified /fec/
direct
On 10/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
> One approach then would be to ensure this never happens, i.e., add a
> small epsilon to each input stream, and make epsilon small enough to not
> sufficiently impact the results for "typical" input values. Normalizing
> the conjugate prod
1) Has anybody ever noticed a case where gr.head doesn't seem to limit the
amount of data that flows through it? I have (some data source) -> (head) ->
(file sink), and sometimes the writing to the file shuts off appropriately,
other times it seems to skip over the limit and would happily consume m
All-
I was hoping I could get some advice on what is a good block-design strategy
for the following problem.
I have two streams of complex samples coming in. I want a block or sequence
of blocks which outputs the cosine of the phase difference between the two
input streams.
If we could assert th
1))
self.connect(self.mult, self.c2f)
self.connect((self.c2f, 0), self.pre_cr_filt, self.sub,
self.clock_recovery, self.slicer, self)
----- Original Message -
>
> *From:* Steven Clark <[EMAIL PROTECTED]>
> *To:* gnuradio mailing list
> *Sent:* Monday, October 15, 200
On 10/15/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
>
> How does it do with say, 2 samples/sym ?
>
>
A quick run @ 2 samp/sym gave:
Old recv...
xcorr offset: 8
num bits compared: 499987
num bit errors: 1275
BER: 0.00255006630172
Old recv plus...
xcorr offset: 16
num bits compared: 499979
num bi
All-
I've made some improvements to the built-in GMSK demodulator, based mostly
on Simon & Wang's "Differential Detection of Gaussian MSK in a Mobile Radio
Environment". Also see "Differential Detection of GMSK Using Decision
Feedback", Yongacoglu, A.Makrakis, D.Feher, K.
The intermediate
, self.nop, self.delay, (self.mult, 0))
self.connect(self.nop, (self.mult, 1))
self.connect(self.mult, [other stuff here], self)
This runs without complaint, but doesn't seem like any data is getting
through...
On 9/24/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
&
hi all-
Quick question about syntax for connecting components inside a
hier_block2...
Let A = hier_block2's input
Let's say I want a mult inside that multiplies A and a delayed version of A
together.
self.delay = gr.delay(gr.sizeof_gr_complex,
2*self._samples_per_symbol) #2T delay
As an arbitrary example, symbol rate 7812.5 sym/sec: have the usrp
decimate by 256 and you're still at 32 samp/sym. What is the best way to
partition decimation between hw and sw? Which sw blocks are ideal for this?
On 9/21/07, Matt Ettus <[EMAIL PROTECTED]> wrote:
>
> Steven C
Hi all-
please look at this sequence of eye diagrams:
http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches
These are from a gmsk mod/demod pair, showing the output of the TX's
gaussian filter (blue) overlaid with the output of the RX's fmdemod (red).
BT = 0.35.
At 8 samples per symbol,
ete.
I have no problem with leaving this sleep in, I just thought this might be
indicative of something that needs to be looked at.
Tom- good to hear from you again. Hope school is going well.
-Steven
On 9/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
>
> Steven Clark wrote:
Pardon the bump...anyone have any ideas?
On 9/13/07, Steven Clark <[EMAIL PROTECTED]> wrote:
>
> Hi all-
>
> I am testing out the blks2.mod_pkts & blks2.demod_pkts with something
> similar to what is in the benchmark_loopback example, only I do not use the
>
Hi all-
I am testing out the blks2.mod_pkts & blks2.demod_pkts with something
similar to what is in the benchmark_loopback example, only I do not use the
USRP at all. Basically, I am transfering the contents of one audio file to
another by way of a mod/demod packet chain, and hoping to see the sam
It seems that this change has broken GRC (complains about non-existent
gr.runtime).
Josh, is there an ETA on a fix for this? Any short-term work-arounds in the
meantime?
-Steven
On 8/27/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
>
> I have recently checked in the updates to the hierarchical
Hi all-
I'm following the instructions at
http://gnuradio.org/trac/wiki/UbuntuInstall.
Hardware is an HP/Compaq nc6230 laptop.
Ubuntu Fiesty Fawn
uname -a gives:
2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
Install seemed to go smoothly, but make check fails on the test
Brett-
I am also very interested in wrapping a C-based FEC library. Could you
please keep us updated with your progress?
Thanks.
-Steven
On 5/25/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Thu, May 24, 2007 at 07:07:09PM -0500, Brett L. Trotter wrote:
> Brett L. Trotter wrote:
> > I've mad
gnuradio community.
Thanks for the support.
-Steven
On 5/22/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Mon, May 21, 2007 at 04:19:58PM -0400, Steven Clark wrote:
> If I need pin-level access to the DAC chip, sink_s is my only option
AFAIK.
> I understand that it's in
If I need pin-level access to the DAC chip, sink_s is my only option AFAIK.
I understand that it's interleaved I&Q, don't worry about that.
My original questions remain.
On 5/21/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Mon, May 21, 2007 at 10:48:04AM -0400, Steven C
Hi all-
Several quick questions.
1) For usrp sink_s, which bit of the short activates the MSB of the DAC
chip? I.e., if I send 0bABCDEFGH IJKLMNOP, where each letter is either a 1
or a 0, which letter matches the MSB?
2) If I want to generate a stream of alternating zeros and ones (stored in
byt
es to it. You need to set permissions so the open will work
Echo "Hello World" > /dev/ttyS0
should send a byte stream out to the first serial port on the machine.
You can use "stty" to set the port speed and other parameters. Se "man
stty" or just "stty --help&q
Hi all-
I've been desparate lately for a way to stream data from GNURadio back out
to the hardware world without turning the data into an analog signal via the
USRP's DAC. For example, if I have a software demodulator outputting bits (1
bit per byte, as done via a slicer in many of the examples),
Hi all-
I noticed that both the usrp.source and usrp.sink blocks have the ability to
specify the .rbf bit file for the FPGA.
Does that mean that in the following:
self.usrp_in = usrp.source_c (fpga_filename="file_A.rbf")
self.usrp_out = usrp.sink_c (fpga_filename="file_B.rbf")
Only file_B ha
(Sorry for sending this twice, Pawel, I forgot to send to list. Also I
corrected a minor error I made)
Hi Pawel-
You've probably figured this out by now, but I ran into the same thing
yesterday. Here's what I did.
in_mux_value = usrp.determine_rx_mux_value(self.usrp_in,
in_dcard_subdev_spec)
pr
Using your perfect samples (the ones you get with decim=8), can you
try low pass filtering them (without decimating) to the equivalent
width that you'd get with the decim=256 setting, and then plotting
them?
Maybe it's not perfectly round because with the narrower filter, we're
losing more of th
kd4.jpg
signal is going in to RX at -10dBm, default gain setting.
On 3/14/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Wed, Mar 14, 2007 at 09:47:20PM -0400, Steven Clark wrote:
> Plots of USRP decimation woes:
> input is GMSK waveform @ ~30ksym/sec, BT = 0.35, no noise added
&g
Plots of USRP decimation woes:
input is GMSK waveform @ ~30ksym/sec, BT = 0.35, no noise added
using decimation rate of 16:
http://img339.imageshack.us/img339/4467/d16cz9.jpg
top plot is complex baseband, bottom plot is amplitude of top plot
some amplitude variations noticeable, but fairly minor.
There is always an unknown phase between the transmitter and receiver.
In addition, the clocks between the transmitter and receiver are never
running at exactly the same frequency. FWIW, the oscillator on the
USRP is spec'd to 50ppm.
Eric
GMSK is a constant amplitude modulation. So unless I
Eric: many thanks for your responses. My responses below:
On 3/14/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Wed, Mar 14, 2007 at 03:45:32PM -0400, Steven Clark wrote:
> Hi all-
> Two very different questions for you:
>
> 1) As a test, I am sending a GMSK signal (c
Hi all-
Two very different questions for you:
1) As a test, I am sending a GMSK signal (created by a signal generator,
very low noise) at low symbol rates into the USRP and plotting the complex
baseband that reaches the PC. One would expect to see a nice tight unit
circle, and at low decimation r
Is it possible to use a spare pin on the USRP (say, for example, on a
daughtercard) as a signal sink?
In other words, if I have a char signal stream in software, in which only
the bottom bit of the 8 bits is active, how do I get that bit back out into
hardware-land?
Many thanks for your time (ev
I have been experimenting with the gmsk demodulation block, and am able to
successfully demod 50M+ continuous pseudorandom symbols at 2.0 MSym/sec.
Kudos to the USRP + GNURadio devs for making that possible, and thanks for
making GNU Radio open-source.
The testing methodology so far has been to o
Is there any reason why the Costas carrier recovery loop used in the
dqpsk.py example would not be suitable for similar use in a gmsk receiver?
TIA
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/
'lo all.
We are trying to use the USRP with the new gmsk demod block, and are
encountering some weirdness.
To generate our GMSK signal, we are using an Agilent signal generator.
BT=0.35, 125 ksymbols/sec, 2 samples/symbol, with a PN15 as the data source.
We load the produced slicer.dat into Matl
You are right, I was using a newer w32api (3.8-1). Thanks for your help!
-Steven
On 11/21/06, Don Ward <[EMAIL PROTECTED]> wrote:
The trouble is occuring during the installation of wxPython. I know this
is "just" a GUI environment, but I'd still like to get it working. I get to
step 6 of http
Hello all-
I'm new to GNU Radio, and was trying to get a development environment set up
in windows using Cygwin, in order to play with a USRP.
I'm matching http://gnuradio.org/trac/wiki/CygwinInstallMain as closely as I
can.
The trouble is occuring during the installation of wxPython. I know thi
92 matches
Mail list logo
