Hi all,
I am currently working on tranmiting and receiving data using 2
USRPN210s.
I got some ideas from here and did this task using GMSK in GRC.
The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD
sink.
The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File
sink.
Data in file source can be received by the receiver. However, I am not
sure
whether the data has been received correctly. Does anyone know how to
test
it ?
My method is to use wav source and audio sink like this:
The transmit side: Wav source --> Packet encoder --> GMSK Mod --> UHD
sink.
The receiver side: UHD source --> GMSK Demod --> Packet decoder -->
Audio
sink. (samp_rate 48K).
I think if the sound received on the receiver is the same as the wav
file,
the data may be correctly received. However, after I tried this, the
sound
received was disjointedly, not as smooth as the wav source, and “audio
underrun” happened sometimes.
However, when I put all the blocks in one flow graph without UHD like
this:
wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet
decoder --> audio sink.(samp_rate 48K), it works very well.
Does anyone meet the same problem or know how to solve it? Is my way to
test how to receive correctly right?
To do what I want, is there any other blocks that need to be added in
the
GRC?
Please give me some guidance.
Thanks in advance.
Jamie
I was messing with the same thing myself.
First off, i’m not sure the packet decoder outputs in a real-time
fashion
to drive an audio sink. Try a scope sink to see how often the packet
decoder output updates: is there a better way?
On the GMSK demodulator side, I would think its best to observe the
signal
going into the demodulator, from uhd rx source. To see it in time
domain,
you can use Quadrature Demod -> throttle -> scope sink, making sure
signal
is centered at 0 and is reasonable distortion free. To be sure what its
supposed to look like, you can put on the transmitter side Quadrature
Demod
-> throttle -> scope sink on the output of GMSK modulator.
And of course you can put an FFT sink right on the UHD source to see it
in
frequency domain. On the transmitter side, to UHD sink, I have found
the
GMSK modulator outputs signal level near the maximum, meaning some
transient peaks could cause clipping on USRP transmitter, so it might be
prudent to put a multiply const (with 0.99 or so) just before going to
UHD
sink.
On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts
[email protected]wrote:
Hi Wayne,
Thanks for your reply. My responses are:
I was messing with the same thing myself.
First off, i’m not sure the packet decoder outputs in a real-time fashion
to drive an audio sink. Try a scope sink to see how often the packet
decoder output updates: is there a better way?
I am not sure the real-time fashion to drive an audio sink either, but
there should be a way to support it, I guess. I ran the flow graph and
saw
the update time interval from a scope sink is 3 - 5s . Is this too long?
Do you know what does this update time mean?
On the GMSK demodulator side, I would think its best to observe the
signal
prudent to put a multiply const (with 0.99 or so) just before going to UHD
sink.
I used Quadrature Demod → throttle → scope sink on the receiver side
to
see the signal going into the GSMK demod after uhd source. Also I
used Quadrature Demod → throttle → scope sink after the output of GMSK
mod. The time and frequency domain outputs are attached. Theoretically,
these two output should be similar or the same, However, they are quite
different after travelling over the air. Can you see any problems from
the
figures?
Thanks,
Jamie
You should use FFT sink with complex input, so its direct from uhd
source
with only throttle in between.
But the FFT you attached seems to indicate you have no signal into the
receiver.
Make sure they’re on the same RF frequency, and adjust gains appropriate
for the path loss between transmitter and receiver.
I am sure the packet encoder/decoder has some overhead, because its
adding
preamble, access_code, and crc.
It means the thruput should be less than your actual over-the-air
bitrate.
If you are sending audio, then you might be better served by one of the
audio encoders, such as the stuff under Vocoders category.
On Thu, Apr 26, 2012 at 12:08 AM, Jamie Wo [email protected]
wrote:
the update time interval from a scope sink is 3 - 5s . Is thistoo long? Do
you know what does this update time mean?
Yes, these run in “real-time.” If they didn’t, you wouldn’t be
properly able to transmit or receive on an actual piece of hardware.
peaks could cause clipping on USRP transmitter, so it might be prudent to
put a multiply const (with 0.99 or so) just before going to UHD sink.
I usedQuadrature Demod → throttle → scope sink on the receiver side to
see the signal going into the GSMK demod after uhd source. Also I
usedQuadrature Demod → throttle → scope sink after the output of GMSK
mod. The time and frequency domain outputs are attached. Theoretically,
these two output should be similar or the same, However, they are quite
different after travelling over the air. Can you see any problems from the
figures?
Don’t use a throttle when you have a block that’s already setting the
rate of your flowgraph. The USRP receiver is controlling that. Having
two rate-controllers in there is at best not needed and at worst
actually screwing up your receiver.
Tom
Hi Javier,
The sample rate of the UHD is 240KHz (uhd source and sink),
the samples/symbol is 2(Packet encoder and Decode) and the bits/symbol
is
1(Packet Encoder). Other parameters are set by default.
The sample of the audio sink is 48KHz as the wav file is sampled at
48Khz.
So I added rational resampler on both sides. I also tired to set the
sample rate at 48Khz without changing it during the process.
Any ideas?
Thanks,
Jamie
My parameters setting
Hi Huzaifa,
I increased the sampling rate, but the problem is still there. Can you
give
me some details on what you have done to solve this problem?
Thanks!
Jamie
On Thu, Apr 26, 2012 at 12:05 AM, Huzaifa Zafar
Yes, thanks, Wayne.
The FFT shows that the spectrum on the transmit and receive side are
similar. Does this mean I receive correctly?
Have you measured the overhead of the packet encoder/decoder ? The
amount
of data I received is much less than the amount I sent. What is your
case?
Jamie
Hi Tom,
Thanks for your reply. It works.
I met another strange problem. When I use Wav file source --> audio
sink,
I can hear the sound in the wav file clearly. However, when I want to
hear
the file and transmit it using UHD sink at the same time, audio underrun
“aUaU” occur. The flow graph is like:
Wav file source --> Package Encoder --> GMSK Mod --> UHD sink.
–> Audio sink
Do you know what is the problem?
Jamie
On Fri, Apr 27, 2012 at 1:58 AM, Jamie Wo [email protected]
wrote:
→ Audio sink
Do you know what is the problem?
Jamie
When you get the audio underruns, do you hear the sound at all? Or are
the underruns continuous.
If they are continuously happening, you have a mismatch in the sample
rate at some point in the flowgraph.
If it’s intermittent, that’s probably the notorious “two-clock
problem.” Both the USRP and audio device have their own clocks that
are running at different rates, though close. Since they will slip
against each other, the frequency of which is dependent on how
different the clocks are, then you’ll have this problem. Usually it’s
not so bad that you can’t hear things, and you might get a clicking
sound as there’s some loss here and there due to it.
Tom
Hi Jamie, My name is Vivian, I am working with DPSK and GMSK mod/demod
too. Do you know how to measure the overhead of the packet
encoder-decoder
?
I could see that in the first images that you attached you weren’t
receiving a good signal at the receiver. But in the other images you are
receiving a good signal. What changes did you do? Can you attached the
flow
graph, I mean the grc squematic. I have been working on this for a long
time and I haven’t could be able to solve this problem because I cant
receive anything. I would aprreciate any help you could give me.
Also, I have found the same problem with the wave file that you mention
here.
Thanks a lot.
Vivian.
2012/4/27 Jamie Wo [email protected]
I was trying GMSK at sample rate of 192000Hz with a samples-per-symbol
of
8, which gives 24000bps.
I connect packet decoder output to file sink set to byte and
Unbuffered:On,
then i use shell script to check the size difference every second.
After
running for 100 seconds or so, it shows around 23336bps, which means
packet
overhead of just under 3%.
attached is shell script i used to watch the file sink grow.
maybe there is a better way, but it seems to get pretty close.
On Fri, Apr 27, 2012 at 7:25 AM, Vivian Paola Triana G. <
Hi Vivian,
I do not know how to measure the overhead. You may refer to Wayne’s
reply.
Please see the flow graphs attached which may be able to solve your
problem.
Jamie
On Sat, Apr 28, 2012 at 12:25 AM, Vivian Paola Triana G. <
Hi Jamie, My name is Vivian, I am working with DPSK and GMSK mod/demod
too. Do you know how to measure the overhead of the packet
encoder-decoder
?
I could see that in the first images that you attached you weren’t
receiving a good signal at the receiver. But in the other images you are
receiving a good signal. What changes did you do? Can you attached the
flow
graph, I mean the grc squematic. I have been working on this for a long
time and I haven’t could be able to solve this problem because I cant
receive anything. I would aprreciate any help you could give me.
Also, I have found the same problem with the wave file that you mention
here.
Thanks a lot.
Vivian.
Hi Vivian,
Sorry for the delay.
I cannot see anything probelm from your grc graphs. It looks like you
have
already received signals from the transmitter. My suggestion is to check
the parameters of packet decoder, GMSK demod, gain, etc. Hope you can
sovle
it.
Regards,
Jamie
On Wed, May 2, 2012 at 10:35 AM, Vivian Paola Triana G. <