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.
No comments:
Post a Comment