Re: [Discuss-gnuradio] Transmit and receive suing GMSK

[wayne roberts]

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 Galeano <address@hidden> wrote:

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 <address@hidden>

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 3:53 AM, Tom Rondeau <address@hidden> wrote:

On Thu, Apr 26, 2012 at 12:08 AM, Jamie Wo <address@hidden> wrote:
>
>
> On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts <address@hidden>
> 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?

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.

>> 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.
>
>
> 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?

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

sink_size.sh
Description: Bourne shell script