Hello Marcus, thanks for your reply. I've fixed the root cause of the issue, which was indeed that I was scheduling the commands way too much in advance. I am generating a waveform and at each pulse I set a tag with the next transmission time. I've however noticed that I need a few samples with value 0 after a pulse, otherwise the pulse will be cut off before being finished. I've tried this with sample rates up to 56 MHz without issue now.
Best regards, Tim Vancauwenbergh Op di 19 nov 2024 om 17:28 schreef Marcus D. Leech <patchvonbr...@gmail.com >: > On 19/11/2024 11:02, Tim Vancauwenbergh wrote: > > Dear, > > > > I am revisiting an issue I encountered earlier. I have a flow that > > generates pulses with spaces between them continuously. To switch > > between the RX and TX paths on a single antenna, I tried utilizing > > GPIO to control an RF switch. > > > > Tests were conducted on a B210 and X310. Initially, I used GPIO tags > > on a USRP sink, but this caused continuous underruns. A sample rate of > > 4 MHz was used. I then switched to using bursts in combination with > > ATR, but the issue persists. The USRP is unable to keep up, resulting > > in significant underruns. > > > > My goal is to send pulses at specific times and have the GPIO state > > follow accordingly. When sending 0s or no samples, the GPIO state > > should be low; otherwise, it should be high. > > > > Could you advise on how to achieve this? I have attached my embedded > > Python block code, which is positioned just before the USRP sink > > block. This block adds the tags for the start and end of bursts and > > handles the initial GPIO setup. For reference, I have also included > > the manual GPIO control block. > > > > Thank you for your assistance. > > > > > > Best regards, > > > > Tim Vancauwenbergh > > > Generally "U" underruns are caused by your *host computer* being unable > to "keep up" with the USRP, NOT the other > way around. The USRP internal performance is entirely deterministic. > If you program it to take in 4Msps, it will > be able to do that forever. > > I'll note that Python blocks DO NOT PERFORM at the same performance > level as C++ blocks. By a significant margin. > I note that in one of your blocks, you're individually iterating > through samples looking for some kind of trigger. > This is guaranteed to have very poor performance characteristics, and > is unlikely to be able to "keep up" at anything > beyond perhaps 1Msps, but that will depend very much on your computer. > > Also, (and I don't know if this is your issue), you can't schedule timed > buffers hugely in advance of when they will > actually get scheduled on the hardware--the hardware has very little > buffering. > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
