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

[John Malsbury]

" 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
>
>