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 < motis1232...@gmail.com> 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 <weijunming2...@gmail.com> > >> 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 <t...@trondeau.com> wrote: >> >>> On Thu, Apr 26, 2012 at 12:08 AM, Jamie Wo <weijunming2...@gmail.com> >>> wrote: >>> > >>> > >>> > On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts < >>> wroberts92...@gmail.com> >>> > 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
sink_size.sh
Description: Bourne shell script
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
