Hi Marcus,
Thank you for your respond,
I just realize it seems somebody in the mail list has the same exact
problem with me, but i check noone has answered to the problem.
I have tried to run
./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,addr1=192.168.50.2"
--channels "0,2" --ref "external" --pps "external".
But i got the same problem, only one light from 2 channel is turned on
(Red), and after that the benchmark rate freeze. The second time i run
benchmark rate after i force quit (ctrl+c) i got error message saying BIST
failed (code:1), and have to turn the power off and turn on both usrp to
make it work again.
However the problem doesnt appear if i try benchmark rate with only 1
address and both channel (channel "0,1"), or trying to run benchmark rate
with only rx_rate. When i try to run
/benchmark_rate --rx_rate "1e6" --args "addr0=192.168.40.2,addr1=192.168.50.2"
--channels "0,2" --ref "external" --pps "external".
I can see both RX channel turned green, and no error appear.
Is it possible something might happen with the tx front end? Please give me
some advice how to solve this.

Thank you for your respond

Regards,
Harfan

On Sun, May 20, 2018, 02:21 Marcus D. Leech <mle...@ripnet.com> wrote:

> On 05/19/2018 12:13 PM, harfan ryanu wrote:
> > Hi Marcus,
> > Thank you for your respond,,
> > That is one of the solution i am thinking right now, but to be able to
> > send zero and turn the gain, i believe i have to use multi usrp object
> > using only one stream to send to both channel right?
> Yes.
>
> > However i got another problem when i try multi usrp object, during the
> > tx_streamer->send command only one channel is transmitting for a few
> > second (only one red LED is on in TX/RX), and after that the
> > application freeze. It is not happening with the rx channel, when the
> > application execute rx_streamer->recv all the channel specified in
> > channel args has the green light ON. I dont know why it only happen
> > with the TX only not with the RX. Do you have any idea why could this
> > happen?
> >
> >
> My guess is that there's an issue in your code.  Since this scenario is
> known to work reliably.  Assuming you're running a standard FPGA image and
>    haven't modified UHD in any way...
>
>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to