The lights are on because the device isn't instructed to stop streaming on
program stop, and it will continue loopback operation after the host has
closed the program. You can manually issue a stream command to stop the
stream before program stop if you want to change this behavior.
Kei, why would the flow go through the host at all in the example you
initially posted? The DMA FIFO exists on the FPGA.
Sam, the headers don't have to be modified in the FPGA if UHD instructs the
RX Radio to omit timestamps.
Nick
On Fri, Mar 9, 2018 at 10:57 AM Samuel Prager <spra...@usc.edu> wrote:
> 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=lULa9TR4NJ1DoZfClmFNcizbjW_7CEHe30UVLpQdlEA&s=OGyLKyNqHC3_9atzXmgn01Vur8l7IUC-zbMtyhULDCs&e=>
>>>>>
>>>>
>>>
> _______________________________________________
> 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
