Wont switch until txtime occurs. Sorry. John On Jun 3, 2013 6:10 PM, "Miklos Maroti" <mmar...@gmail.com> wrote:
> Hi John, > > On Mon, Jun 3, 2013 at 8:00 PM, John Malsbury <john.malsb...@ettus.com> > wrote: > > You see "L" because you are sending your bursts far enough advance > > > > should have read: > > > > "aren't sending your bursts far enough in advance" > > > > > > On Mon, Jun 3, 2013 at 5:59 PM, John Malsbury <john.malsb...@ettus.com> > > wrote: > >> > >> " It'll switch to TX when it receives samples to send." > >> > >> There may be some small [intentional] delays, but the FPGA will switch > to > >> Tx on the first sample to be sent. Josh can specify the timing in more > >> detail. > > You say that it switch from TX to RX if the next timestamp is in the > future and switch from RX to TX just when the timestamp is triggered. > > >> You see "L" because you are sending your bursts far enough advance. In > my > >> applications, the bursts are sent to the USRP about ~5ms before the > actual > >> transmission. > > Ok, I will try to send them 5ms before transmit time, that should > work. But then synchronizing the FPGA clock with the PC clock will be > more trouble. > > >> And as far as I know you can't just use the fractional > >> seconds. The FPGA won't switch to TX when it hits tx_time and starts > clock > >> out the samples. > > You say that the FPGA will NOT change from RX to TX? This contradicts > the other sentences you wrote. > > Miklos > > >> > >> -John > >> > >> > >> On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti <mmar...@math.u-szeged.hu > > > >> wrote: > >>> > >>> Hi John, > >>> > >>> Thanks for you quick reply, but you did not answer any of my > >>> questions. Will the FPGA switch from TX to RX when it has already > >>> received from the host a UDP packet with a timestamp tag (tx_time) > >>> that is in the future? Also, when exactly will the RX to TX switch > >>> occur? > >>> > >>> Miklos > >>> > >>> On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury <john.malsb...@ettus.com > > > >>> wrote: > >>> > If you choose TX/RX as both your transmit and receive antenna, the > FPGA > >>> > will > >>> > switch between TX and RX automatically. It'll switch to TX when it > >>> > receives > >>> > samples to send. > >>> > > >>> > -John > >>> > > >>> > > >>> > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti <mmar...@gmail.com> > >>> > wrote: > >>> >> > >>> >> Hi Guys! > >>> >> > >>> >> I am trying to develop a half duplex application with N210 and SBX > >>> >> daughterboard with the latest (git head) gnuradio that needs precise > >>> >> TX/RX switching times (like in TDMA) in the order of a few samples > >>> >> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags > and > >>> >> they do not seem to solve the problem. My findings so far are: > >>> >> > >>> >> 1) tx_sob/tx_eob does not influence anything related to the TX/RX > >>> >> switch, it only controls the grouping of the TX data stream into UDP > >>> >> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last > >>> >> UDP packet even if it is not full). The same is true for USRP1 but > >>> >> that uses USB packets. > >>> >> > >>> >> 2) tx_time is translated into the metadata_t struct in the host code > >>> >> and then it is translated into VITA packet time stamps (converts the > >>> >> fractional second part into sample numbers). The integer part of > >>> >> tx_time seems to be discarded, but I still get "L" (timestamp in the > >>> >> past error), so I do not understand why the FPGA will not wait a > >>> >> little if only the factional part is considered. > >>> >> > >>> >> 3) I have found this discussion online about TX/RX switch: > >>> >> > >>> >> > >>> >> > http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html > >>> >> > >>> >> where Matt Ettus said that "The act of transmitting turns off the > >>> >> receiver, so no amount of software will ever change that." in > >>> >> discussing half duplex operation. Now it is not clear if that > comment > >>> >> is also applicable to the N210 and SBX, and what does he mean by > "the > >>> >> act of transmitting". Specifically, if I send a packet with tx_time > in > >>> >> the future, does the FPGA switches to RX mode while it is waiting? > >>> >> > >>> >> 4) We have looked up the FPGA code, and it seems that the timing is > >>> >> implemented in a short FIFO when handling the VITA UDP packets. I > >>> >> could not trace the code further, and I do not see the logic in the > >>> >> FPGA code that does the automatic switching between RX and TX. Where > >>> >> is that implemented? > >>> >> > >>> >> 5) Is it true that to switch between RX and TX then the host has to > >>> >> issue a command (poke register) to update the appropriate pin on the > >>> >> FPGA? If so, then how can you time the update of that pin to > specific > >>> >> sample numbers? > >>> >> > >>> >> 6) Is it true that the firmware soft core has nothing to do with the > >>> >> time sensitive data and control handling, so in particular the > >>> >> provided register access features (if I saw them correctly) are not > >>> >> used in timing sensitive paths? > >>> >> > >>> >> 7) It is not clear how the gnuradio UHD sink block handles the > sample > >>> >> rate value in the presence of tx_time tags. For example, if I > generate > >>> >> 10 small packets each of which has a tx_sob,tx_time and tx_eob and > 0.1 > >>> >> sec delay between the times, and all of these small packets are put > >>> >> into the transmit fifo at once, then what happens? What is the rate > >>> >> that the UHD sink block will consume this data? It cannot be the > >>> >> sample rate, because these tags point to the future, so the > >>> >> consumption rate should be reduced, but is it what happens? Will the > >>> >> code switch the TX/RX switch to RX between the small packets if all > >>> >> those are already in the queue? > >>> >> > >>> >> I hope someone has answers to these questions. Searching the > internet > >>> >> turned up next to nothing on these subjects. > >>> >> > >>> >> Miklos > >>> >> > >>> >> _______________________________________________ > >>> >> Discuss-gnuradio mailing list > >>> >> Discuss-gnuradio@gnu.org > >>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > > >>> > > >> > >> > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
