Inject "tx_time" tags in a stream
Hi, all! I am working on a proof of concept of a radar system for my doctoral thesis. I recently installed the great gr-pdu and gr-timing utilities from Sandia Labs and I am trying to develop a little application with GNURadio Companion (GRC), based on a USRP N200 system. I essentially want to use the rising edges of a pulsed signal to generate another signal. For this purpose, first the trigger signal is sampled with a USRP-Source block, then is threshold detected by means of a "Threshold trigger" block and finally, a message with a "Tag message trigger" block is generated. The output of this last block feeds a "PDU to Bursts" block which enters a USRP-Sink. I have checked with a "Tag Debug" that the threshold detection and message generation are both working fine. At the output of the "PDU to Bursts" block, each burst is tagged with the "tx_sob" and "tx_eob" tags. The problem arises when those burts enter the USRP-Sink. As far as I've read, this blocks transmits all burts sequentially ignoring the time separation that should be between them. Please, take into account that the trigger pulses are not equally separated in time, so I must transmit one burst with each received pulse. I think the issue is that no "tx_time" tags are being generated and added to each burst. I wonder if anyone have the same explanation for this issue, and hopefully, if anyone can guide me on how can I inject those "tx_time" tags properly in my stream with GRC. Any help will be appreciated! Regards, José
Re: Inject "tx_time" tags in a stream
Has anyone worked with tx_time tags? jnu...@uvigo.es escribió: Hi, all! I am working on a proof of concept of a radar system for my doctoral thesis. I recently installed the great gr-pdu and gr-timing utilities from Sandia Labs and I am trying to develop a little application with GNURadio Companion (GRC), based on a USRP N200 system. I essentially want to use the rising edges of a pulsed signal to generate another signal. For this purpose, first the trigger signal is sampled with a USRP-Source block, then is threshold detected by means of a "Threshold trigger" block and finally, a message with a "Tag message trigger" block is generated. The output of this last block feeds a "PDU to Bursts" block which enters a USRP-Sink. I have checked with a "Tag Debug" that the threshold detection and message generation are both working fine. At the output of the "PDU to Bursts" block, each burst is tagged with the "tx_sob" and "tx_eob" tags. The problem arises when those burts enter the USRP-Sink. As far as I've read, this blocks transmits all burts sequentially ignoring the time separation that should be between them. Please, take into account that the trigger pulses are not equally separated in time, so I must transmit one burst with each received pulse. I think the issue is that no "tx_time" tags are being generated and added to each burst. I wonder if anyone have the same explanation for this issue, and hopefully, if anyone can guide me on how can I inject those "tx_time" tags properly in my stream with GRC. Any help will be appreciated! Regards, José
Re: Inject "tx_time" tags in a stream
Hi Derek, Thank you very much for your detailed response. I thought that tag's insertion could be done directly from GRC. I hoped that there would be some library to insert these tags in a stream. The truth is that I don't have enough knowledge to write my own block. On the other hand, I think my problem (which is essentially a burst stream synchronized with a trigger signal) is conceptually very simple and must have been encountered by many more people before. I've searched the whole forum and it's not like that. I am also surprised that no one else has answered my question. Regards, José Hi Jose, You'll have to write a block to add those tags where you want them in the stream (at the start of each burst) and with the time you want them at (the time is relative to the USRP's internal timekeeper clock). You'll also need to read from or set the time on that clock at the start of the application. The first part you can do with an embedded Python Block to add those tags. The second part you'll either need to modify the generated Python flowgraph or use the very latest 3.9 development code which added the Python Snippets block. https://github.com/gnuradio/gnuradio/pull/3169 Ettus Research's UHD manual includes a helpful page on synchronization and how to read/set the time. https://files.ettus.com/manual/page_sync.html Regards, Derek On 27/02/2020 19:33, jnu...@uvigo.es wrote: Has anyone worked with tx_time tags? jnu...@uvigo.es escribió: Hi, all! I am working on a proof of concept of a radar system for my doctoral thesis. I recently installed the great gr-pdu and gr-timing utilities from Sandia Labs and I am trying to develop a little application with GNURadio Companion (GRC), based on a USRP N200 system. I essentially want to use the rising edges of a pulsed signal to generate another signal. For this purpose, first the trigger signal is sampled with a USRP-Source block, then is threshold detected by means of a "Threshold trigger" block and finally, a message with a "Tag message trigger" block is generated. The output of this last block feeds a "PDU to Bursts" block which enters a USRP-Sink. I have checked with a "Tag Debug" that the threshold detection and message generation are both working fine. At the output of the "PDU to Bursts" block, each burst is tagged with the "tx_sob" and "tx_eob" tags. The problem arises when those burts enter the USRP-Sink. As far as I've read, this blocks transmits all burts sequentially ignoring the time separation that should be between them. Please, take into account that the trigger pulses are not equally separated in time, so I must transmit one burst with each received pulse. I think the issue is that no "tx_time" tags are being generated and added to each burst. I wonder if anyone have the same explanation for this issue, and hopefully, if anyone can guide me on how can I inject those "tx_time" tags properly in my stream with GRC. Any help will be appreciated! Regards, José
