Re: [Discuss-gnuradio] Transmit and Received Signals are Different

[Frederick Lee]

Frederick,

all kinds of stuff can go wrong.

When you say you see 'nothing' on the FFT sink, do you mean you see only
noise, or literally nothing?

Here's a typical ist of things I do when debugging such a link:

1) Use a spectral analyzer to see if the transmitter is actually
transmitting (where you want it to)
2) Connect an FFT sink directly to the UHD source to see if the signal
looks as expected

You've got a couple of things that surprise me in your FG:
- the packet decoder (I'm not 100% what that does) searches for a bit
string? If so, you have no way to guarantee you're actually receiving
that specific sequence. If you're literally rx'ing nothing, perhaps that
doesn't trigger.
- Why do you LPF bits?

Hi Martin,

I have done more testing and am looking into the way the packet encoder and modulation blocks work.

First off, I was able to fix the issue of not being able to see the signal on the scope sink ( I was actually not seeing anything last time. i.e. completely blank ). The problem being I didn't put a multiply const block with a value of 100m in front of the USRP sink. I think this was needed to lower the signal strength so that the receiving daughter board was able to process the signal. I don't remember what the max dB the RFX2400 daughter board can handle, but from what I saw it seems to be about -50dB. This was seen on a FFT sink directly connected to the USRP source.

Second, putting the bits through a low pass filter was an error on my part. I had the LPF there from before, and had left it there thinking I needed to cut off unwanted frequencies. It turns out that I don't need one at all. If I use the packet decoder and the demodulation block, it reproduces the original signal. From what I understand so far, the packet encoder adds transmitting information ( preamble, access code, whitener offset, and whatever is returned from the whiten function, though I am not sure what the whitener offset and whiten function is for ), converts it to network byte order ( big endian ), and applies a CRC before sending this "packet" out. The packet encoder doesn't look like it touches the signal data at all, which seems kind of odd.

Lastly, is it normal for the scope sink to update so slowly? For example, If I change the amplitude or frequency of the transmitting wave, it takes about 30 seconds before I see a change in the scope sink on the receiving laptop. The FFT sink which is connected to the USRP source directly updates in 2-3 seconds. Could the packet decoder and demodulation block slow the scope by that much? The sample rate of the flow graphs are 200k, so I was wondering if this is normal behaviour.

Thanks for all the help,

Frederick