On 07/12/2022 07:49, 能书能言 wrote:
The number of data packets in ① is not correct, but the number of
data packets in ② is correct. Therefore, to avoid more problems, I
choose ②.
By viewing the pictures in the attachment and your explanation, f_
RF is LO frequency? Then the two channels share one LO, so setting f_
Offset adjusts the frequency to f_ target?
I tried the following:
freq1= 2.4G
freq2= 2.39G
lo_off1= 5M
lo_off2= -5M
samp_rate=300K
But the problem still exists, and the bit error rate is very high : (
Another thing I forgot to say is that I did a dual channel
transmission experiment before (I call it experiment A. ), and the
parameter settings are the same as when I first set them（freq1 = 2.4G,
freq2=2.39G, lo_off1=2M, lo_off2=-2M,samp_rate=300k）,which performs
very well. The only difference between experiment A and this
experiment now is that the modulation of the signals on the RFA and
RFB of experiment A are different. I copied the USRP sink and USRP
source components directly from the GRC of experiment A, and the
parameter settings are the same, experiment A performed very well, but
in this experiment a high BER occurred, so now I am confused where the
problem lies
Best regards！
You need to look *in detail* about how tune_request works.
In particular, the default policy for both the rf_freq and the dsp_freq
is *AUTO*, which is not what you want in this case:
https://files.ettus.com/manual/structuhd_1_1tune__request__t.html
You likely want to tune the LO to half-way between your two desired
frequencies, and then use DSP offsets from that.
With a policy of "auto", it will try to tune the chip so that the
specified frequency appears in the baseband, but using
an offset tuning--that's not *quite* what you want.
You need to specify the same (in-the-middle) rf_freq for both channels,
with MANUAL policy, and set the DSP offset
appropriately, again with MANUAL policy.
