Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission

Brian, I think your idea does work. I think the tricky bit to doing this really well is having a control loop that reacts quickly enough that we don’t have to be stuck with a giant buffer that adds undesirable latency, but then conversely a control loop that adapts at a slow enough rate and with

Re: [USRP-users] link led colour

Interestingly, my X310 front panel LED occasionally, very briefly shows red too. Maybe the schematic isn’t current with what is actually used in the unit these days(?). Regards, Joe > On Mar 7, 2019, at 3:36 PM, Marcus Müller via USRP-users > wrote: > > So that's built on an X3x0 platfo

Re: [USRP-users] link led colour

So that's built on an X3x0 platform. As said, no, the link leds really just display link status, nothing about the data. Also, when you look at the schematic of the X300, PDF [1] page 13, you'll find no red LED – only green and yellow, so I must admit I'm a bit confused about what you witnessed? B

Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission

On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller wrote: > I've had rather longish discussions on how to solve this; essentially: > for something that actually *solves* the issue (instead of postponing > it), as Ian said, you'd need to have clock domain crossing ability. > Could message passing from

Re: [USRP-users] link led colour

I am using USRP 2955 R Koyel Das Senior – Product Engineer Vehere | Proactive Communications Intelligence & Cyber Defence M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com [unnamed]

Re: [USRP-users] link led colour

The link LEDs on our USRPs don't indicate validness of data. It's highly likely this is normal. What USRP are you using? Best regards, Marcus On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users wrote: > Hi, > > When I am receiving data using ethernet my link LED is orange most o

Re: [USRP-users] Frequency resolution of UBX-160 with integer N mode

Good description! If you look into uhd/host/lib/usrp/dboard/dboard_ubx.cpp (I think), you should find that the constructor looks through all the rates the motherboard (X310 in your case) has to offer and picks the highest one that works with your UBX. That'd be 25 MHz for the 0. revision of the UBX

Re: [USRP-users] [B210] ERROR_CODE_TIMEOUT when recv_frame_size > 8184

Thank you Ron, Your suggestion did solve my problem, I moved back to v3.13.0.3-rc1 and now I can use larger frame sizes. With increased frame size and a RAM disk I can now achieve a full capture rate of 61.44MSps on Odroid XU4. Regards, Kris On 2/8/19 12:45:47, Krzysztof Wisniewski via

Re: [USRP-users] Frequency resolution of UBX-160 with integer N mode

Hi Fabian Thank you for your answer. I have check the schematics of the X310. The reference clocks to the daughter boards and the 200 MHz sampling clocks are both generated by the "clock jitter clean" chip (LMK0481). I did not have time yet to check the configuration of this chip, but probably yo

[USRP-users] How To Reset a Previously JTAG-Programmed Image For Use Over PCI-e Interface for USRP X310

Hello all, I have a USRP X310 and I previously programmed it through JTAG with its latest image for 10GbE. Now I got a PCIe x4 cable and as far as I know, the image through this interface is programmed for each session. I have read in a few places that the JTAG programmed image could cause a prob