Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

[Miklos Maroti]

Hi John,

On Tue, Jun 4, 2013 at 7:38 PM, John Malsbury <address@hidden> wrote:
> Miklos,
>
> I'm not sure if what you're saying is correct.  Switch U3 may not switch to
> RX2 during tx in half-duplex operation.  I would double check, but I don't

Thanks! What I have observed, that adding an antenna to the RX2
connector does change the received samples during transmission, i.e.
it overdrives it more.Maybe I am mistaken somewhere, but would
appreciate if you would double check. From earlier discussions it
seems that ATR state machine controls this behavior, right?

> think it matters either way.  If this is a half-duplex application, you
> don't want to receive and transmit at the same time.  So you should just
> ignore samples from the uhd_source, or mute them while tx is enabled.  In
> this case, it doesn't matter what the RX path sees while it is switched to
> the RX2 path.

That is true, that I have to discard those samples anyways. However, I
am worried that overdriving the receive path during transmission would
have adverse effect on subsequent reception (few samples right after
the TX -> RX switch). Do you think that is a real concern?

Miklos

>
> -John
>
>
>
> On Tue, Jun 4, 2013 at 5:23 PM, Miklos Maroti <address@hidden>
> wrote:
>>
>> Hi John,
>>
>> Thanks for the excellent suggestion! It seems to work reliably with
>> 5ms buffering. I did not set the time of the FPGA, nor did I
>> synchronized the FPGA with the host. I just used the received sample
>> counter for all timings on the host to determine (the 5ms buffering)
>> when to send the samples to the board.
>>
>> One question: It seems to me that when the TX -> RX switch is done,
>> then actually the N210 will use the RX2 antenna instead of
>> disconnecting the RX channel completely from the TX/RX antenna. Is it
>> possible to force half duplex operation, i.e. to completely disconnect
>> the RX channel. Of course I woulds still see leakage through the
>> board, but maybe that will not overdrive the LNA. Any ideas?
>>
>> Miklos
>>
>> On Mon, Jun 3, 2013 at 7:59 PM, John Malsbury <address@hidden>
>> 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 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.  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.
>> >
>> > -John
>> >
>> >
>> > On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti <address@hidden>
>> > 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 <address@hidden>
>> >> 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 <address@hidden>
>> >> > 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
>> >> >> address@hidden
>> >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >> >
>> >> >
>> >
>> >
>
>