[USRP-users] tlast signal in CHDR
I am working on some existing code of RfNoC on UHD_3.15.0 to process the incoming rx data stream. The CHDR wrapper/unwrapper makes use of the TLAST signal. For a stream of continuous ADC samples, there is no obvious data block boundary such as each line/frame commonly in video. I didn’t study the RF block implementation, if needed I will do that. I am wondering whether anybody can share some knowledge on the condition of TLAST signal assert in the radio block, or the direction to study it. Many thanks in advance. We are hiring consultant for RfNoC development. please contact peiqing@higherground.earth ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] X310 ethernet connection failure
I had problem talking to my x310 device over ethernet. Does anybody have similar experience? The following external hardware are used to test my x310 units: * host PC with 10G intel NIC * 192.168.10.1 static IP, connect to X310 port0 using SFP adaptor & CAT-6 cable * 192.168.40.1 static IP, connect to X310 port1 using genuine 10G cable * Front panel USB cable * power supply My old x310 is tested first to ensure both 192.168.10.2 and 192.168.40.2 are reachable. Its EEPROM is loaded with /usr/local/share/uhd/images/usrp_x310_fpga_HG.bit With the new X310 plugged in, none of 192.168.10.2 and 192.168.40.2 is reachable. No luck with the following additional steps: * confirm the green leds in Port 0 and 1 are on * nothing is found by sudo uhd_find_devices & uhd_usrp_probe * use vivado to download /usr/local/share/uhd/images/usrp_x310_fpga_HG.bit * By intercepting the network ARP traffic, no party acknowledges it is 192.168.10.2 or 192.168.40.2 Keep the external hardware unchanged, switch back to the working x310, both 192.168.10.2 and 192.168.40.2 are reachable. Use vivado to download /usr/local/share/uhd/images/usrp_x310_fpga_HG.bit to the working x310, both 192.168.10.2 and 192.168.40.2 remain working. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310 ethernet connection failure
Problem solved, hoping my note can be helpful for others. This device was previously programmed to use non-default IP addr, something different from 192.168.10.2 and 192.168.40.2 in HG image. I bet the previous owner was doing MIMO study. To bring back the default configuration, re-program the EEPROM. Steps can be found in https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices FYI, the hardware revision label in my unit was placed in a location different from the web-page description, not an issue at all. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310 ethernet connection failure
Hi, Marcus, Thanks for your reply. The clear & precise problem description is an endless pursuit I should try to do better. My experience is a lot of problem get answered by itself when it is described clear enough to the very detail, it’s part of a learning process. My current guess is the FPGA program after JTAG download runs the ZPU to retrieve the existing settings, such as the IP, from EEPROM. The page(s) for setting must live outside the pages used for FPGA image, as the uhd_image_loader process won’t change these settings. This is another entry in my TODO list. Wish everybody a nice weekend. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
