[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] how to deal with "underride"

From: John Malsbury
Subject: Re: [Discuss-gnuradio] how to deal with "underride"
Date: Thu, 13 Dec 2012 15:03:07 -0800

A blob is essentially a pointer with a byte count, and is used to move raw data around with messages. 

The burst gate was a band-aid that was used to move the "tx_eob" tag to the last sample, since this is not assured in the way GNU Radio propogates tags across interpolating blocks like modulators.  It makes a pretty large assumption that all of the samples of a burst are present in the input buffer, which may not always be true - when you change to different modulator for example. 

Can you send your flowgraphs so I can see what you are doing when you modify simple_trx?  It's unclear to me how you would receive the message you mentioned below if you've removed the framer all together.


On Thu, Dec 13, 2012 at 1:35 PM, zhengxiangwei <address@hidden> wrote:
     I think I make some progress. I think the problem are mainly associated with "blob" used in simple_trx. I wonder except John Malsbury, who write simple_trx in pre-cog, if there is anyone who can fix the problem. The problem is to make simple_trx work with other modulation in two host computers, like bpsk, QAM.

 I compared radio block in simple_trx and benchmark_tx and benchmark_rx. Radio_hier of simple_trx can be seen in https://github.com/buoyboy/pre-cog/wiki/A-Simple-Packet-Radio-Example.

I find in the receive path, they are same, except in simple_trx, gr_msg_queue() is set to gr_msg_queue(4) and in benchmark, it is default. 
The detail of receive path is
demodulator, and correlator are modules in gr-digital.

But in transmitter path, there is a big difference.
In simple_trx,

In benchmark

From the codes of framer and burst_gate, I do not really understand how they works. But 

But after I change the transmitter path of simple_trx,(remove framer and burst_gate) it can receive some data from radio, but the data type is not righ, so the recieve host print its address "86" and data receive and "not a blob --simple MAC".

But if I keep them, then modulator fails for DBPSK, but it works for GMSK. It is really strange after changing the modulation, then simple_trx fails to work.

There is some link describe pmt_blob. But I am not sure the advantage of using blob and where blob is defined.

Xiangwei Zheng
Research Assistant
ECE Department, Virginia Tech
Office: Durham Hall 365
Tel: 540-553-6235

From: address@hidden
Date: Thu, 13 Dec 2012 11:16:01 -0500

Subject: Re: [Discuss-gnuradio] how to deal with "underride"
To: address@hidden
CC: address@hidden

On Wed, Dec 12, 2012 at 6:20 PM, zhengxiangwei <address@hidden> wrote:
I think frequency offset may not be the reason.

The attachment is the oscilloscope picture. The first one use DBPSK modulation, which can be received by simple_trx.py. The second one use GMSK modulation, which can be successfully  received by simple_trx.py.

I wonder is there any reason may cause simple_trx.py fail to work using DBPSK.
Thank you.

Xiangwei Zheng

Neither of those figures really shows anything. The bandwidth is way too high. But the fact that the scope is telling you that the signal is clipping might be an indication that you're feeding way too much power into the transmitter.



From: address@hidden
Date: Wed, 12 Dec 2012 12:07:31 -0500
Subject: Re: [Discuss-gnuradio] how to deal with "underride"
To: address@hidden
CC: address@hidden

On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei <address@hidden> wrote:

I compared the difference when using GMSK and PSK in simple_trx.grc which use radio_hier.grc.
When use GMSK, 
it calls
gr_fir_fff: using SSE

When use PSK,
it calls 
gr_fir_ccf: using SSE
gr_fir_ccc: using SSE

Also I compare with benchmark_tx,
when use PSK
it calls gr_fir_ccf: using SSE

when use gmsk
it calls
gr_fir_fff: using SSE

I know c, f means different data type: complex and float.

Is it the reason why PSK fail to work? which calls additional  "gr_fir_ccc: using SSE"?

If it is not the reason, I will dive into framer, which may also cause failure in TX.
Thank you. 

Xiangwei Zheng

No, this is not the reason. This is probably a channel filter used in PSK signals and not in the GMSK signals.

Most likely the reason is frequency offset or too much or too little power.


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]