Sorry I mean the lights were on when I closed the program.
Thanks Sam for the suggestion I will try to take a look into it.
On Fri, Mar 9, 2018 at 2:02 PM, Nick Foster <bistrom...@gmail.com> wrote:
> 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
