Hey Piotr, it took me a bit to respond because this is tricky question. And I still don't have a great answer, but I also don't want to let you hang.
A few thoughts: - Maybe you just want to write an RFNoC block that drops samples in a regular pattern for you. That way you wouldn't rely on timed commands coming in all the time. - Actually, on the TX side, you might use the same thing. As the ATR pins follow the Tx state, you could fall back to not modifying the radio and simply using the standard ATR feature if you had a block that produced bursts the way you want them. Unless of course you want the TX chain to be running continuously, which might be the case here. - Timed commands to the radio could also come from the FPGA, although we don't have a good example for that. But the radio doesn't care who's sending the timed commands. Another RFNoC block could be sending stream commands in a regular fashion. --M On Tue, Oct 1, 2024 at 11:10 AM <per...@o2.pl> wrote: > Hello all, > > I know the topic of triggering of transmission and reception has been > recurring here on the list over and over. But I haven’t found the answer > that is good for my case among the previous threads . > > The context: I'm using USRP X410 and I’m transmitting a pulsed radar > waveform. I’m able to receive the return signal continuously, but I need to > limit the stream of data sent to the PC. The good solution is to send > precisely selected part of the received signal after each pulse. This way > the radar can focus only on the most interesting area. For example to > define: receive ‘N’ samples beginning in ‘R’ samples from the Tx pulse > start (where ‘N’ and ‘R’ can be changed but it doesn’t happen often). > > My current implementation with continuous reception looks like this: I’m > using USRP X410 and in RFNoC I have a ‘Replay’ block connected to the > DUC->Radio block. ‘DUC’ has upsampling set to ‘1’ - that make it pass > samples without change from ‘Replay’ block. The ‘Replay’ block plays in a > loop a pulse followed by zeros. The least significant bit of I part of IQ > sample is connected to GPIO port and is used currently to control the RF > front-end (switch between transmission and reception). This way I’m loosing > one bit of transmitted IQ sample, but I have very precise control over the > GPIO, so that it is synchronized with Tx pulse. For example, I can set that > line a bit earlier than RF pulse in order to prepare the Tx chain for > transmission. > > Now in order to achieve what I described (receive ‘N‘ samples after each > pulse) I wanted to reuse for triggering the reception the signal that > currently controls the GPIO. > > And here my question starts: where in RFNoC should I connect the > triggering signal and implement the logic that controls passing the samples > synchronously with the trigger? > > I wanted to implement an RFNoC block that passes the samples synchronously > with the trigger. In order to that I'll have to edit manually the RFNoC > flowgraph in order to connect the trigger signal to additional input in the > block (I can do that). I have doubt if I can trigger an event synchronously > with the samples stream this way, but at the moment I have more basic > issue. I don’t know yet how to ignore samples for arbitrarily long time > with RFNoC use of block. I think the closest thing that exists in UHD to > what I'm trying to do is rfnoc_keep_one_in_n. I'm trying to use some ideas > from it but I've got no success yet. > > Another solution could be use the trigger to control flow of the samples > from ADC to the radio block, but I don’t know yet exactly how it could be > implemented. > > Maybe there is some better solution to that what I’m trying to do? Maybe I > can use timed commands? But I don’t want to send them from PC as I would > have to do that very often: for each pulse and pulse rate might be i.e. > 2kHz. > > Trying out each option means loosing more time - so maybe you have some > advice which path is most promising? > > Best Regards, > Piotr Krysik > _______________________________________________ > 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
