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 Wed, Apr 25, 2012 at 9:08 PM, 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? > > > 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? > > Thanks, > > Jamie > > >> >> On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo <weijunming2...@gmail.com>wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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
