discuss-gnuradio
[Top][All Lists]
Advanced

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

?????? ?????? ?????? Problems implementing USRP b210 dual channel transc


From: ????????
Subject: ?????? ?????? ?????? Problems implementing USRP b210 dual channel transceiver
Date: Wed, 21 Dec 2022 17:21:39 +0800

Sorry I forgot to put the file


------------------ ???????? ------------------
??????: "????????" <2127629883@qq.com>;
????????: 2022??12??21??(??????) ????5:18
??????: "Marcus M??ller"<mueller@kit.edu>;"discuss-gnuradio"<discuss-gnuradio@gnu.org>;
????: ?????? ?????? ?????? Problems implementing USRP b210 dual channel transceiver

Hi,
    I'm sorry that I was delayed last week. I conducted some experiments again (test_tx, test_rx in the attachment). I found that the two signals have been successfully separated under this setting and will not interfere with each other. Therefore, I believe that the cause of high bit error rate may be somewhere else. The other two GRCs in the attachment are what I want to achieve. I found this phenomenon:
    I removed one of the "FEC extended decoders" on the receiving end (rx), and the other one performed very well. However, as long as the two "FEC extended decoders" modules existed at the same time, the bit error rate would become extremely high. I don't know what happened. I also didn't get a detailed explanation about this module from the official website.
Best Regards,
linge93

------------------ ???????? ------------------
??????: "Marcus M??ller" <mueller@kit.edu>;
????????: 2022??12??8??(??????) ????6:23
??????: "discuss-gnuradio"<discuss-gnuradio@gnu.org>;
????: Re: ?????? ?????? Problems implementing USRP b210 dual channel transceiver


On 12/7/22 13: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 ??.
You were probably operating on a different frequency than you've thought!
> 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?
Exactly!
>      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 : (
well, there might be many reasons for that; one might be that the
sampling rate of 300 kHz is very low for the USRP, so filtering might be
suboptimal.
> 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.

But you cannot have been operating on the frequencies you thought you
were using, so that success is a bit meaningless?

Best regards,

Marcus

> 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??
>
>
> ------------------ ???????? ------------------
> *??????:* "Marcus M??ller" <mmueller@gnuradio.org>;
> *????????:* 2022??12??7??(??????) ????5:37
> *??????:* "discuss-gnuradio"<discuss-gnuradio@gnu.org>;
> *????:* Re: ?????? Problems implementing USRP b210 dual channel
> transceiver
>
> Sorry, typo, hit ctrl-enter to send accidentally when trying to fix
> it. Let me say it
> correctly:
>
> Re: ?? But you receive packets! So that's a good thing, I guess?
>
> Re: ?? So, maybe the attached figure helps. The offset is the
> difference between the
> physical LO frequency f_{RF}, and the center frequency of what becomes
> your baseband.
>
> So, I incorrectly said "the offsets need to add up to 10 MHz"; correct
> would be to say that
> freq1-offset1 = freq2-offset2.
> Now, since freq2 = freq1 - 10 MHz follows
> freq1-offset1 = freq1 - 10 MHz - offset2
> 10 MHz = offset1 - offset2
>
> Note that offsets can be negative.
>
> Best regards,
> Marcus
>
> On 07.12.22 10:30, Marcus M??ller wrote:
> > Your LO offset still don't add up to the difference between freq1
> and freq2. What
> > frequency is the physical LO supposed to have? It cannot have
> frequency 2.4 GHz - 5 MHz
> > and 2.39 + 2 MHz at the same time. These are different numbers!
> >
> > Best regards,
> > Marcus
> >
> > On 07.12.22 09:09, ???????? wrote:
> >> Hi,
> >>      Thank you for your reply, based on your suggestion I have
> tried the following:
> >>      ??No LO offset set (no uhd.tune_request)
> >>         Ch0:Center Freq : freq1
> >>         Ch1:Center Freq : freq2
> >>         ??freq1 = 2.4G, freq2=2.39G,samp_rate=300k??
> >>       ??Set LO Offset
> >>         Ch0:Center Freq : uhd.tune_request(freq1,lo_off1)
> >>         Ch1:Center Freq : uhd.tune_request(freq2,lo_off2)
> >>         ??freq1 = 2.4G, freq2=2.39G, lo_off1=5M,
> lo_off2=5M,samp_rate=300k??
> >>       or ??freq1 = 2.4G, freq2=2.396G, lo_off1=2M,
> lo_off2=2M,samp_rate=300k??
> >>       or ??freq1 = 2.4G, freq2=2.396G, lo_off1=2M,
> lo_off2=-2M,samp_rate=300k??
> >>
> >>      for ????
> >>      In this case, the number of packets received is incorrect and
> the problem becomes
> >> more serious.
> >>      for ????
> >>      In this case the BER is still very high (I don't think it's my
> system because the
> >> transmit power is set to 1 (Normalized) and the BER is quite low
> when using one RF
> >> channel, but I still think I'm using the USRPB210's dual channel
> transmission mode
> >> incorrectly)
> >> Best Regards??
> >>
> >> ------------------ ???????? ------------------
> >> *??????:* "Marcus M??ller" <marcus.mueller@ettus.com>;
> >> *????????:* 2022??12??6??(??????) ????8:49
> >> *??????:* "discuss-gnuradio"<discuss-gnuradio@gnu.org>;
> >> *????:* Re: Problems implementing USRP b210 dual channel transceiver
> >>
> >> There's only one physical TX LO; so either you just don't specify
> offsets, OR they must
> >> add up to the difference between the two target frequencies.
> >>
> >> In your case, the difference is 10 MHz, but your offsets don't add
> up to 10 MHz, and
> >> you're requesting something impossible.
> >>
> >> Best regards,
> >> Marcus
> >> On 06.12.22 12:45, ???????? wrote:
> >>  > Hi,
> >>  >      I am using OFDM + USRPB210 for data transmission. I am
> using two USRPB210s, one
> >> being
> >>  > used as a transmitter and the other as a receiver. When I use
> only one of the channels
> >>  > (RFA or RFB) the data can be transmitted properly. I needed to
> transmit two different
> >> data
> >>  > at the same time, so I used both the USRP RFA and RFB. the
> baseband processing part
> >> of the
> >>  > link was the same for both channels (including channel coding,
> modulation, FFT,
> >> etc.), but
> >>  > at this point I found that I was transmitting data with a very
> high BER (for both
> >> links).
> >>  > again, mentioning that there was no problem when sending on one
> channel alone, I The
> >> USRP
> >>  > Sink and Source settings are shown in the attached picture.
> >>  >      where
> >>  >      freq1=2.4G
> >>  >      freq2=2.39G
> >>  >      lo_off1=2M
> >>  >      lo_off2=-2M
> >>  >      samp_rate=300K
> >>  >     The two signals are separated using different frequencies, I
> don't think there
> >> should
> >>  > be any interference between them, and I have troubleshot errors
> other than USRP
> >> source and
> >>  > sink, so I think there is something wrong with my parameter
> settings, or I am using the
> >>  > two RF channels in an incorrect way. How should I modify
> this?Looking forward to your
> >>  > response??
> >>  >
> >>  > Best Regards!
> >>  >

Attachment: test_rx.pdf
Description: Binary data

Attachment: test_tx.pdf
Description: Binary data

Attachment: semantic_demo_tx_double.pdf
Description: Binary data

Attachment: semantic_demo_rx_double.pdf
Description: Binary data


reply via email to

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