Hello,
I have had this issue and may be able to help. I believe that is because the rx
packet headers need to be modified before the radio will transmit them. I would
suggest looking at the siggen block and making a new ‘relay’ noc block between
the rx and tx in the fpga that modifies headers appropriately. I would guess
that the lights are on because you have filled up all fifos.
Sam
On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the
> errors anymore and I can run the flowgraph without having to power cycle. I
> think that is because the flow doesn't go through the host anymore. But it's
> weird that after stopping the flowgraph the RX and TX lights are still on.
> Why is that?
> By the way still I can't receive the relay signal in USRP 3.
>
> > On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster <bistrom...@gmail.com> wrote:
> > > Are you using a custom FPGA image? What happens if you just omit the DMA
> > > FIFO?
> > >
> > > Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
> > > is a good start.
> > >
> > > Nick
> > >
> > > > On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen <hai.n.nguyen...@gmail.com>
> > > > wrote:
> > > > > Thanks for the reply and sorry for not providing much information. My
> > > > > case is that I want to do a relay transmission with the setup: USRP 1
> > > > > transmits --> USRP 2 receives and retransmits with a shifted fc -->
> > > > > USRP 3 receives.
> > > > > The problem is in USRP 2, as you pointed out in your post. I'm
> > > > > testing on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC
> > > > > (frequency shifted by 5MHz) --> TX. I used your approach [1] in step
> > > > > 1 of your tutorial (also did step 2 and 3) and rebuilt.
> > > > > At first the flowgraph runs without errors. The TX and RX lights were
> > > > > on, so it seemed to transmit something. But in USRP 3 I didn't see
> > > > > the relay signals (only the original signal that USRP1 transmits).
> > > > > Also, in the following runs, it raised the errors:
> > > > > [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > > > > UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> > > > > [INFO] [X300] X300 initialization sequence...
> > > > > [INFO] [X300] Determining maximum frame size...
> > > > > [INFO] [X300] Maximum frame size: 1472 bytes.
> > > > > [INFO] [X300] Setup basic communication...
> > > > > [INFO] [X300] Loading values from EEPROM...
> > > > > [INFO] [X300] Setup RF frontend clocking...
> > > > > [INFO] [X300] Radio 1x clock:200
> > > > > [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> > > > > [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> > > > > [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> > > > > [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [CORES] Performing timer loopback test...
> > > > > [INFO] [CORES] Timer loopback test passed
> > > > > [INFO] [CORES] Performing timer loopback test...
> > > > > [INFO] [CORES] Timer loopback test passed
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> > > > > kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> > > > > [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > > > > UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> > > > > [INFO] [X300] X300 initialization sequence...
> > > > > [INFO] [X300] Determining maximum frame size...
> > > > > [INFO] [X300] Maximum frame size: 1472 bytes.
> > > > > [INFO] [X300] Setup basic communication...
> > > > > [INFO] [X300] Loading values from EEPROM...
> > > > > [INFO] [X300] Setup RF frontend clocking...
> > > > > [INFO] [X300] Radio 1x clock:200
> > > > > [ERROR] [UHD] Exception caught in safe-call.
> > > > > in virtual ctrl_iface_impl::~ctrl_iface_impl()
> > > > > at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> > > > > this->peek32(0); -> EnvironmentError: IOError: Block ctrl
> > > > > (CE_00_Port_30) packet parse error - EnvironmentError: IOError:
> > > > > Expected packet index: 3 Received index: 4
> > > > > Traceback (most recent call last):
> > > > > File "./relay.py", line 291, in <module>
> > > > > main()
> > > > > File "./relay.py", line 279, in main
> > > > > tb = top_block_cls(freq=options.freq)
> > > > > File "./relay.py", line 72, in __init__
> > > > > self.device3 = device3 = ettus.device3(uhd.device_addr_t(
> > > > > ",".join(('type=x300', "")) ))
> > > > > File
> > > > > "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> > > > > line 1610, in make
> > > > > return _ettus_swig.device3_make(device_addr)
> > > > > RuntimeError: EnvironmentError: IOError: [0/DmaFIFO_0] sr_read64()
> > > > > failed: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet
> > > > > parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00
> > > > > Received SID: 02:c0>00:00
> > > > >
> > > > >
> > > > > which is exactly the errors that Christophe faced in the previous
> > > > > post. I had to power cycle to run the flowgraph again.
> > > > > Attachments are the changed files. I'm using uhd version UHD
> > > > > 4.0.0.rfnoc-devel-409-gec9138eb and gnuradio version
> > > > > 3.7.12git-295-ga0adcd33.
> > > > > Sorry for the long post.
> > > > >
> > > > >
> > > > >
> > > > > > On Fri, Mar 9, 2018 at 12:21 PM, Nick Foster <bistrom...@gmail.com>
> > > > > > wrote:
> > > > > > > You're going to have to ask a better question than that. Please
> > > > > > > provide the following:
> > > > > > >
> > > > > > > * What you are trying to accomplish
> > > > > > > * What hardware you are using
> > > > > > > * What UHD and Gnuradio version you are using
> > > > > > > * The approach you followed
> > > > > > > * The result you expected
> > > > > > > * The result you actually got
> > > > > > > * A flowgraph which exhibits the problem
> > > > > > >
> > > > > > > If you put effort into your question, we can put effort into
> > > > > > > answering you.
> > > > > > >
> > > > > > > Nick
> > > > > > >
> > > > > > > > On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users
> > > > > > > > <usrp-users@lists.ettus.com> wrote:
> > > > > > > > > Hello, is this problem resolved? I am facing the same issue
> > > > > > > > > in the last email. Also, I tried to receive the relay signal
> > > > > > > > > with another usrp but it doesn't receive anything in my
> > > > > > > > > transmit frequency.
> > > > > > > > >
> > > > > > > > > Hai
> > > > > > > > > _______________________________________________
> > > > > > > > > USRP-users mailing list
> > > > > > > > > USRP-users@lists.ettus.com
> > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > > > >
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=lULa9TR4NJ1DoZfClmFNcizbjW_7CEHe30UVLpQdlEA&s=OGyLKyNqHC3_9atzXmgn01Vur8l7IUC-zbMtyhULDCs&e=
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
