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. -John On Thu, Dec 13, 2012 at 1:35 PM, zhengxiangwei <zxw...@hotmail.com> wrote: > Hi, > 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 > "uhd_source->channel_filter->demodulator->correlator->frame_sink" > demodulator, and correlator are modules in gr-digital. > > But in transmitter path, there is a big difference. > In simple_trx, > "pad_source->framer->modulator->muliplier->burst_gate->uhd_sink" > > In benchmark > "pkt_input->modulator->amplifier->uhd_sink > > 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. > https://github.com/guruofquality/grextras/wiki > > ================================= > Xiangwei Zheng > Research Assistant > ECE Department, Virginia Tech > Office: Durham Hall 365 > Tel: 540-553-6235 > > > > > ------------------------------ > From: t...@trondeau.com > Date: Thu, 13 Dec 2012 11:16:01 -0500 > > Subject: Re: [Discuss-gnuradio] how to deal with "underride" > To: zxw...@hotmail.com > CC: discuss-gnuradio@gnu.org > > On Wed, Dec 12, 2012 at 6:20 PM, zhengxiangwei <zxw...@hotmail.com> 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. > > Tom > > > > > > ------------------------------ > From: t...@trondeau.com > Date: Wed, 12 Dec 2012 12:07:31 -0500 > Subject: Re: [Discuss-gnuradio] how to deal with "underride" > To: zxw...@hotmail.com > CC: discuss-gnuradio@gnu.org > > > On Wed, Dec 12, 2012 at 11:49 AM, zhengxiangwei <zxw...@hotmail.com>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. > > 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
