And here's a flowgraph with some of the recommendations above (attached).

-John Malsbury


On Fri, Mar 28, 2014 at 12:12 AM, John Malsbury <[email protected]>wrote:

> To expand on Martin's comments, here are some of the issues that *could*
> be present:
>
>    - Add a mult_const block or otherwise reduce the amplitude of the i/q
>    signal going to the usrp_sink from +/- 1.0 to 0.5 or 0.7.  This ensures you
>    are not non-linear in the transmitter.
>    - tx and rx_gain -> if you have these two devices a few feet apart
>    (3-5 dB for both tx and rx should work)
>    - Frequency errors between the two USRP devices (or is this on a
>    single device?)   Ultimately, you could include some automatic, course
>    frequency correction
>    - In my experience, the GMSK demod will lock within 100-200 symbols.
>    Since this is a continuous streaming flow graph driven by the random
>    source, transient behaviour shouldn't be an issue.  You should have a
>    continuous stream of samples to lock to.  So I don't think lock/sync time
>    for the clock recovery is an issue.
>    - Have you changed any parameters on the packet encoder/decoder blocks
>    from the defaults?  What is the bit/symbol and samps/symb set to?  What's
>    the samps/symbol set to on the gmsk mod and demod?
>    - Instead of a random source, test with a vector source and a known
>    pattern.
>    - To give a quick sanity check on your encoder/decoder config, connect
>    the two *without* any channel.  If that doesn't work, you definitely have
>    some config issues.
>
> Also, once you're through with this experiment, you might consider using
> gr-mac, which provides similar functionality.  Balint and I have been
> hacking on it late tonight, you can find the latest here:
>
> https://github.com/balint256/gr-mac
>
> Also, a known working version that is a bit older and less bleeding edge:
>
> https://github.com/jmalsbury/gr-mac
>
> http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p31.pdf
>
> -John
>
>
> On Thu, Mar 27, 2014 at 1:52 AM, Martin Braun <[email protected]>wrote:
>
>> On 03/26/2014 12:30 PM, Ank wrote:
>> > Hello all,
>> >    I'm working on gmsk transmitter and receiver past 6 months , the
>> problem
>> > that I'm facing is in the packet decoder.
>> >
>> >   I tried with wav file and signal source it worked good.
>> >
>> >   my block is of this type
>> >
>> >
>> >
>> Random_source=>Packet_encoder=>gmsk_modulator=>rational_resamlper_1=>uhd_sink
>> >
>> >
>> >
>> uhd_source=>rational_resampler_2=>low_pass_filter=>gmsk_demodulator=>packet_decoder=>scope_sink/file_sink
>>
>> There are a lot of things that can go wrong in this setup. Maybe the
>> sync is not locking fast enough, and destroying the preamble. It's hard
>> for us to figure this out from a distance.
>>
>> Try replacing the UHDs with a channel model, and go crazy with that. See
>> what happens.
>>
>> M
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>

Attachment: gmsk_link_sim.grc
Description: application/gnuradio-grc

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to